4 ms·

what makes code totally unreadable for me, is when people think adding more smaller classes and more smaller functions is actually simplifying the code. NO! NO!

by ki_ 4y ago

what makes code totally unreadable for me, is when people think adding more smaller classes and more smaller functions is actually simplifying the code. NO! NO! NO! You are splitting up the code and spreading it around so i cant see the whole picture and make it very difficult for me to track which function calls what function. After 20 goto definitions... i mean. common. abstracting your code is making it more complex. or. maybe im just working with terrible developers that dont know how to abstract in a simple way. Anyway, i dont like it. Procedural programming is best in my opinion. And if you are going to abstract, dont use too many layers. e.g. A calls B calls C and D, and D calls also C and C sometimes calls E and E calls B. etc... TOTAL NIGHTMARE.

dstick 4y ago
Yeah I never got that whole "a function can never be longer than X lines". Screw that. Put everything that's relevant in that context in the function and only start breaking things up once it has to be re-used. Which happens a lot less often than many books and guides make out to be.
- toto444 4y ago
  I once read a comment or post on HN that was saying something around the line : 'good code is code that you can throw away easily'. A long function that can be broken down easily meets that criterion.
- Akronymus 4y ago
  Also, internal functions/lambdas first before exposing it externally makes the most sense in many cases. Reduces namespace pollution and makes it easier to rewrite those inner ones.
xupybd 4y ago
This depends. If you don't mix levels of abstraction you can use your functions to build something close to a DSL. I would have agreed with you when I was 5 years in but now I like small functions and lots of the. Each function have one narrow easy to test task.
dolni 4y ago
Bit of a shortsighted assessment IMO. Systems abstract tons of stuff that you don't see, even being a programmer. And not having to worry about that is VERY convenient. It sure is nice to not have to give a rip about how to arrange data on a hard drive, or speak network protocols directly. What you are actually looking for is code that operates in the correct problem domain. That requires abstraction which is done correctly. My guess is that you have worked on codebases with crappy abstractions.

by ki_ 4y ago

dstick 4y ago

Yeah I never got that whole "a function can never be longer than X lines". Screw that. Put everything that's relevant in that context in the function and only start breaking things up once it has to be re-used. Which happens a lot less often than many books and guides make out to be.

toto444 4y ago
I once read a comment or post on HN that was saying something around the line : 'good code is code that you can throw away easily'. A long function that can be broken down easily meets that criterion.
Akronymus 4y ago
Also, internal functions/lambdas first before exposing it externally makes the most sense in many cases. Reduces namespace pollution and makes it easier to rewrite those inner ones.

xupybd 4y ago

This depends. If you don't mix levels of abstraction you can use your functions to build something close to a DSL. I would have agreed with you when I was 5 years in but now I like small functions and lots of the. Each function have one narrow easy to test task.

dolni 4y ago

Bit of a shortsighted assessment IMO. Systems abstract tons of stuff that you don't see, even being a programmer. And not having to worry about that is VERY convenient. It sure is nice to not have to give a rip about how to arrange data on a hard drive, or speak network protocols directly. What you are actually looking for is code that operates in the correct problem domain. That requires abstraction which is done correctly. My guess is that you have worked on codebases with crappy abstractions.