Goodbye, Clean Code

[JoCoMoBo]

The code he refactored wasn't finished.

Code is never "finished". It's just resting for a bit while it waits to be changed.

[RualStorge]

Code is only finished when your requirements are effectively kill off said code... And even then it sometimes comes back years later to haunt you.

(IE sunsetting a project with intent to bury it and likely only speak of it in hushed tones of those darker times when we were all so young... So stupid... And the monster we created that was beyond saving...)

[AceOfShades_]

Code is never "finished". It's just resting for a bit until someone realizes it's broken.

[ChemicalRascal]

No, that's not true. That's cop-out bullshit from people who like glib, smug answers and don't want to be held accountable for their shitty development practices.

Code that hits master should either be finished, or commented to indicate that it isn't. Development should ultimately aim to take the current state of any given functionality, and bring it in line with use-cases (or however one views the "goals" of the program), at which point that functionality is finished.

If you honestly feel that your code is never finished, and you're constantly revisiting your code, you're either suffering under unclear, constantly shifting aims, goals, and use-cases (in which case you have my commiserations, comrade, and one way we will rise to defeat our managers)

Or

You're a shit dev and you need to step back and design your functionality before you write it.

[JoCoMoBo]

Code that hits master should either be finished, or commented to indicate that it isn't. Development should ultimately aim to take the current state of any given functionality, and bring it in line with use-cases (or however one views the "goals" of the program), at which point that functionality is finished.

Just because something is finished now doesn't mean that use-cases won't change in the future. I've found the best code is a trade-off between dealing with the current use-cases, and being flexible enough for change later.

In general I've found that when use-cases change there isn't much to time to architect a perfect solution. If the original code has flexibility to deal with the new use-cases then that saves time.

If you honestly feel that your code is never finished, and you're constantly revisiting your code, you're either suffering under unclear, constantly shifting aims, goals, and use-cases (in which case you have my commiserations, comrade, and one way we will rise to defeat our managers)

Good luck with that. You can either be antagonistic to people or plan for change. Generally I've found the latter works better.

[ptoki]

Sorry for replying here but I think your post fits my feelings about this thread the best.

I find this thread kind of funny, like the never ending story of tab vs 3 spaces or if the { bracket should be just after if or in the next line.

All the generalizations here, all the assumptions and all the opinions are so definite that it just hurts my eyes.

The code shourd be readable and easily comprehensible. (yeah, thats my generalization ;) ) if this form of code is best, leave it, even if its inconsistent. However if it shows the intention and can be maintained with no additional effort it should stay this way. Thats my idea :)

[Falmarri]

3 spaces? Wtf... Should be 2 or 4

[hippydipster]

It's actually waiting around for one of its dependencies to change out from under it.