3 ms·

Clean code to me is like good writing. It should be easy to read and comprehend later. The rules are not rules but guidelines. I think OO centric rules are har

Clean code to me is like good writing. It should be easy to read and comprehend later. The rules are not rules but guidelines. I think OO centric rules are harmful in a word where languages support functional programming etc. Polymorphism isn’t always the best answer. A big nested if statement that reads like the business spec can be easier to follow and reason about. That aside if easy to understand code makes your app a bit slower, you profile to work out why and fix up the bits that matter making the tradeoff where it is needed. Writing code for what you think will be performant everywhere, and not caring about readability in the process is a fools errand, at least in most SaaS/Web/Business apps.

thenoblesunfish 4y ago
And another similarity to good writing - sometimes you really do need to have really dense, precise stuff that isn't easy to understand without a close read. You put that into an appendix when writing, and into optimized low level routines/libraries when writing software. That way you can make things readable, but still have the "performance".
jbverschoor 4y ago
Yep.. I much prefer 2000 lines of code in one function with very little calls. Easier to reason about, less bugs, easier to maintain. It's very easy to indicate when a new part is coming, just enter a big comment block of what you're doing.
- mxmbrb 4y ago
  This is the perfect example. You start out like that and all is fine, but two years, a few changes and some bugfixes later your now 2700 line method is a total zombie. The comments blocks are lying and you have incromprehensible dependencies. More over you have to read it all every time you make a change in the method, its inputs or understanding its output. That just screams 'refactor me!'. The exceptions of course are when initializing a lot, or having a ton of bindings, etc. No need to cramp this into sub methods like its a religion. Cramping code may be fine for high performance code where the mandays are justified for the two line code fix. But in most Software you likely just want to include the new cache methods, change the used object, add a button or fix an update. And the person fixing it probabaly hasn't seen the specific code ever before. There is sadly no need for high performance software, when you can't sell it in time.
  - jbverschoor 4y ago
    Still better than nested classes and 50 different places where the code is. There are plenty of places where it makes more sense. Also in 'normal' code. It's about readability and maintainability. Classes mean -> extensibility, and is by definition more complex. Factoring out some functions make sense yes, but not the general mantra "if it's 5 lined it should be a function". As Uncle Bob says (paraphrasing): Dependency injection (java) is just programming XML where you turned compiler errors into runtime errors
  - curtainsforus 4y ago
    If you want logical separation, add sub-blocks to the function. You can see things as being a spectrum from fully inline code, to code blocks, to anon functions defined in the function, to true functions.

thenoblesunfish 4y ago

And another similarity to good writing - sometimes you really do need to have really dense, precise stuff that isn't easy to understand without a close read. You put that into an appendix when writing, and into optimized low level routines/libraries when writing software. That way you can make things readable, but still have the "performance".

jbverschoor 4y ago

Yep.. I much prefer 2000 lines of code in one function with very little calls. Easier to reason about, less bugs, easier to maintain. It's very easy to indicate when a new part is coming, just enter a big comment block of what you're doing.

mxmbrb 4y ago
This is the perfect example. You start out like that and all is fine, but two years, a few changes and some bugfixes later your now 2700 line method is a total zombie. The comments blocks are lying and you have incromprehensible dependencies. More over you have to read it all every time you make a change in the method, its inputs or understanding its output. That just screams 'refactor me!'. The exceptions of course are when initializing a lot, or having a ton of bindings, etc. No need to cramp this into sub methods like its a religion. Cramping code may be fine for high performance code where the mandays are justified for the two line code fix. But in most Software you likely just want to include the new cache methods, change the used object, add a button or fix an update. And the person fixing it probabaly hasn't seen the specific code ever before. There is sadly no need for high performance software, when you can't sell it in time.
- jbverschoor 4y ago
  Still better than nested classes and 50 different places where the code is. There are plenty of places where it makes more sense. Also in 'normal' code. It's about readability and maintainability. Classes mean -> extensibility, and is by definition more complex. Factoring out some functions make sense yes, but not the general mantra "if it's 5 lined it should be a function". As Uncle Bob says (paraphrasing): Dependency injection (java) is just programming XML where you turned compiler errors into runtime errors
- curtainsforus 4y ago
  If you want logical separation, add sub-blocks to the function. You can see things as being a spectrum from fully inline code, to code blocks, to anon functions defined in the function, to true functions.