10 ms·

+1 I had a lot of trouble trying to explain this to juniors. The most important things is to have code that is easy to refactor when you know what you're doin

+1 I had a lot of trouble trying to explain this to juniors. The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse than into a code that would be 10k lines in one file, but with a flat structure and less interdependency.

BurningFrog 5y ago
> The most important things is to have code that is easy to refactor Very true. I'll just add that another most important thing is to actually take time to refactor, even when things are busy. I spend maybe 1/3 of my time refactoring, and that feels good.
- jimbokun 5y ago
  I like to refactor once I have passing tests and before committing. Once you know it works take a minute to clean up and make the changes fit your preferred style, extract repeated code into shared methods, comment the tricky bits, etc.
  - BurningFrog 5y ago
    This Is The Way
gary_0 5y ago
"Flat is better than nested" - The Zen of Python I had an "everything should be broken into a hierarchy!" stage back when I was learning to code, and boy was I off track. In my defense, at the time (and this dates me) OOP was all the rage.
- icedchai 5y ago
  I find OOP spaghetti can be incredibly difficult to navigate, example: Class hierarchies 4 or 5 layers deep, some subclasses overriding the parent, others not. It can be it very difficult to follow what's actually going on. Procedural spaghetti is more manageable, though I once had to update a C app with a 3000 line case statement. Pure madness.
  - arealaccount 5y ago
    Inheritance hell would be more lasagna code. Golang does a good job of addressing this one particular problem.
  - jamesfinlayson 5y ago
    I remember working on a project with endless exception class hierarchies - that was a monumental pain when trying to diagnose what led to an exception. In a subsequent project we banned subclassing of exceptions.
Scarblac 5y ago
Less interdepency is absolutely the key to everything. But... isn't the easiest way to show that there is little interdepency to put them in separate files that don't import from each other?
- lanstin 5y ago
  People misjudge where to draw the lines. You will have an orchestration API call that does five things and each of those five things, not used anywhere else, will get its own class, interface, factory, and configuration, so to read thru the five things you have to open like twenty files. And to notice that despite all this engineering they have static credentials in the code itself, you have to be alert across so many lines of code. The whole thing can be one longer file that reads coherently and in fact lessens the cross class importing.
lupire 5y ago
> The most important things is to have code that is easy to refactor This whole post is about how refactoring doesn't matter because your project's development lifetime isn't long and wide enough for maintentance to matter.
smackeyacky 5y ago
This depends a lot on the development environment. In Smalltalk years ago, we were encouraged to limit each method to few lines at the most. This makes sense within Smalltalk and the code browsing inherent in the system. It makes debugging in Java or C# an exercise in face shredding frustration. Where each class is in a file, it's better to structure the class consistently with other classes in the project, and things like naming conventions become a lot more important. You could argue that the C/C++/Java/C# languages are fundamentally broken because they don't encourage the succinct, small class methods that Smalltalk did, but you could also argue that those small methods don't necessarily work very well in a different class of languages from Smalltalk and neither approach is really more productive than the other, with the caveat that Smalltalk is largely dead and irrelevent to modern programmers other than a curio.

BurningFrog 5y ago

> The most important things is to have code that is easy to refactor Very true. I'll just add that another most important thing is to actually take time to refactor, even when things are busy. I spend maybe 1/3 of my time refactoring, and that feels good.

jimbokun 5y ago
I like to refactor once I have passing tests and before committing. Once you know it works take a minute to clean up and make the changes fit your preferred style, extract repeated code into shared methods, comment the tricky bits, etc.
- BurningFrog 5y ago
  This Is The Way

gary_0 5y ago

"Flat is better than nested" - The Zen of Python I had an "everything should be broken into a hierarchy!" stage back when I was learning to code, and boy was I off track. In my defense, at the time (and this dates me) OOP was all the rage.

icedchai 5y ago
I find OOP spaghetti can be incredibly difficult to navigate, example: Class hierarchies 4 or 5 layers deep, some subclasses overriding the parent, others not. It can be it very difficult to follow what's actually going on. Procedural spaghetti is more manageable, though I once had to update a C app with a 3000 line case statement. Pure madness.
- arealaccount 5y ago
  Inheritance hell would be more lasagna code. Golang does a good job of addressing this one particular problem.
- jamesfinlayson 5y ago
  I remember working on a project with endless exception class hierarchies - that was a monumental pain when trying to diagnose what led to an exception. In a subsequent project we banned subclassing of exceptions.

Scarblac 5y ago

Less interdepency is absolutely the key to everything. But... isn't the easiest way to show that there is little interdepency to put them in separate files that don't import from each other?

lanstin 5y ago
People misjudge where to draw the lines. You will have an orchestration API call that does five things and each of those five things, not used anywhere else, will get its own class, interface, factory, and configuration, so to read thru the five things you have to open like twenty files. And to notice that despite all this engineering they have static credentials in the code itself, you have to be alert across so many lines of code. The whole thing can be one longer file that reads coherently and in fact lessens the cross class importing.

lupire 5y ago

> The most important things is to have code that is easy to refactor This whole post is about how refactoring doesn't matter because your project's development lifetime isn't long and wide enough for maintentance to matter.

smackeyacky 5y ago

This depends a lot on the development environment. In Smalltalk years ago, we were encouraged to limit each method to few lines at the most. This makes sense within Smalltalk and the code browsing inherent in the system. It makes debugging in Java or C# an exercise in face shredding frustration. Where each class is in a file, it's better to structure the class consistently with other classes in the project, and things like naming conventions become a lot more important. You could argue that the C/C++/Java/C# languages are fundamentally broken because they don't encourage the succinct, small class methods that Smalltalk did, but you could also argue that those small methods don't necessarily work very well in a different class of languages from Smalltalk and neither approach is really more productive than the other, with the caveat that Smalltalk is largely dead and irrelevent to modern programmers other than a curio.