4 ms·

> In my opinion unnecessary abstractions -- especially splitting code up into different files It gets especially bad when someone else wrote that code and you'

by clarry 8y ago

> In my opinion unnecessary abstractions -- especially splitting code up into different files It gets especially bad when someone else wrote that code and you're just getting into it. Layers upon layers of abstractions scattered across classes, functions, files. Each add very little on their own, but you kinda have to keep it all in your head (or write it down as I do) if you're planning to grok it and fix that bug. It's kinda like reading some piece of code not in its final form, but as a pile of diffs are applied to it. Fun. :-) I find older style procedural code with longer functions generally much easier to get into than any OOP.

p1necone 8y ago
As a counterpoint, I find breaking code up into separate classes and functions to help greatly with minimizing what I need to keep in my working memory. I don't often need to know what every single line does exactly all at once, nor can I actually keep that much information in my head anyway. I'd rather be able to say "that's the function that frobbles the subductor, it's 5 lines long and right now I don't care how it does it.", Sure, the bug might be in that function - but if it's only 5 lines long and does one simple thing, I can write a bunch of tests for that one thing and work it out. When the code is broken up like this, I can keep an even larger system in working memory all at once.
- taneq 8y ago
  I think the "functions should be small and do only one thing" maxim is important but needs to be paired with "things should be small and done in only one function." The more you split logic across multiple functions, the more likely that the bug won't be in any one function but in the way that you composed them.
  - rashkov 8y ago
    This is one of the most astute criticisms that I've seen of coding style, along with your earlier post regarding locality of reference and duplication of statements vs duplication of intent. I think these are really great principles for writing clear and beautiful code. Are these ideas something that you've developed from experience? Is there a wider context and conversation around this kind of thing, that you know of?

by clarry 8y ago

p1necone 8y ago

As a counterpoint, I find breaking code up into separate classes and functions to help greatly with minimizing what I need to keep in my working memory. I don't often need to know what every single line does exactly all at once, nor can I actually keep that much information in my head anyway. I'd rather be able to say "that's the function that frobbles the subductor, it's 5 lines long and right now I don't care how it does it.", Sure, the bug might be in that function - but if it's only 5 lines long and does one simple thing, I can write a bunch of tests for that one thing and work it out. When the code is broken up like this, I can keep an even larger system in working memory all at once.

taneq 8y ago
I think the "functions should be small and do only one thing" maxim is important but needs to be paired with "things should be small and done in only one function." The more you split logic across multiple functions, the more likely that the bug won't be in any one function but in the way that you composed them.
- rashkov 8y ago
  This is one of the most astute criticisms that I've seen of coding style, along with your earlier post regarding locality of reference and duplication of statements vs duplication of intent. I think these are really great principles for writing clear and beautiful code. Are these ideas something that you've developed from experience? Is there a wider context and conversation around this kind of thing, that you know of?