11–20 of 72 posts
Yes, just don't use the word "shit". The obvious refactoring is to split the function up into smaller pieces, even if you can split it into two 1500 line functions that is a win.
Is swearing on HN banned now?
What you do is that you:
A) Realize that there might be years of hidden bugs, but also fixes to complex problems, speedups, kludges, weird changes to requirements, etc, hiding in the code, so even really creative unit-test might not cover real-world edge-cases.
B) Take as small bit as you can, and just refactor out the smelly code into smaller parts. Often a good name around smelly code helps a long way.
D) Iterate. Until good enough.But not more... Maybe you have more important things to do than rewriting ugly code that works.
There is a big risk that since you probably won't understand everything that goes on, and why - you will break something important.
1) Understand at a very fundamental level what it does (there are probably multiple things).
2) Understand at a very fundamental level what it does (this is really the hard part)
3) Document your hard-earned understanding (tests, ironically, do not work well for this, since there are no fundamental units to test at, and there likely is a metric ton of shared state)
4) Refactor it into something easier to understand and test.
I've had to work with a similar 5,000 line C function at the heart of a DSL parser; literally the core of the entire business. Changes were made very slowly, and with a lot of consideration. Refactoring is still underway 6 years later.
2. Read the function a few times to get a sense of what it's doing.
3. Break the function into blocks of statements that are performing a related task.
4. Factor those out into smaller functions.
5. Recursively repeat 3-5 until you're satisfied with the new functions' line count.
> Should I tell my manager that the function needs to be refactored and take time to refactor it?
It's absolutely worth mentioning. Time estimations are one of the harder tasks of Software Engineering. Being up front with your manager can help better set expectations.
You test the shit out of it, then re-write it ensuring tests pass, then add your new code. It's probably easier to do that than to muck around in the 2000-line version hoping you don't screw something else up.
Yep, this is the only way to handle these beasts. Don't touch anything. Make a ton of tests. Spend some time validating those tests. Get someone to write off that those tests are sufficient. Start refactoring!
Making the assumption that anybody is capable of sufficiently testing such functions and subsequently re-writing them will only introduce new bugs and old regressions.
Seems harsh, but I've had to work with a few such monstrosities. Global state galore.
I would read the thing a few times and figure out exactly where to add the functionality. Refactor second, if time permits. If the thing is 2k long clearly, refactoring it isn't a priority.
Yes, just don't use the word "shit". The obvious refactoring is to split the function up into smaller pieces, even if you can split it into two 1500 line functions that is a win.
Thanks, that came out of frustration from looking at similar long-sized functions for an extended period of time.
Tell your manager that you want to refactor it. Just don't tell your manager "it's shit".
The "don't say it's shit" was when speaking to the manager... not using it on your thread. Unless I'm the one misunderstanding the statement...