5 ms·

Very good stuff here. I totally agree with many of these points. Especially, these 5. 3. Simplicity is king. 5. Naming is hard, but it's important. 9. Prefer

Very good stuff here. I totally agree with many of these points. Especially, these 5. 3. Simplicity is king. 5. Naming is hard, but it's important. 9. Prefer internal functions over custom solutions. 11. Avoid creating multiple blocks of code nested in one another. 14. Split your classes to data holders and data manipulators. To be honest all of them really feed into number 3. The lower the cognitive burden to reading your code the easier it will be the maintain and work with.

yonixw 8y ago
I disagree with no.11 ... I prefer nested code of if's because as a reader I learn which conditions are relevant and assumed, rather than check-it-all at the start.
- aw1621107 8y ago
  How does checking at the start not convey what conditions are relevant and what assumptions can be made in the rest of the function?
- wongarsu 8y ago
  If I put all my early exits at the start, for the remainder of the function I only have to remember the list of preconditions established by the early exits. With deeply nested code I instead have to keep a stack of currently fulfilled conditions in mind. Sure, at any given point the stack is shorter than the list so there's less things to keep in mind, but for me dealing with mental lists is much easier than dealing with mental stacks.
- ThorinJacobs 8y ago
  What level of nesting are you referring to here? I ask because I experience the opposite - with more than one or two levels of nesting I have difficulty keeping track of the condition the block expects. Depending on the size of the method sometimes even one level can make me stumble a little.
de_watcher 8y ago
Number 14 is funny: it's like "do classes, but don't do what classes actually do". The first paragraph then goes about setters and getters that are specifics of some particular styles in some particular languages (and why you even need setters if you want to be clear about "not manipulating the data"?).
- bunderbunder 8y ago
  #14 fits into a fairly well-established trend of thought on object-oriented programming. A lot of us have noticed, over the 20-ish years since OOP really got popular, that doing it in the way most of us were taught in CS 101 (or wherever) tends to produce code that is difficult to maintain over time. In the particular case of mixing data storage and data manipulation in a single class: It tends to yield classes that continuously accumulate new functionality over time. They also tend to be difficult to refactor int a set of smaller classes. The level of impact on consuming code is very high, because splitting those classes tends to also force major changes to anything that interacts closely with them. And, since all that functionality lived inside a single class, it's likely to be internally resistant to change, too. It's really easy to treat "encapsulation" as a reason to not worry overmuch about shared use of glo^H^H^H instance variables. Does this kind of stuff mean that OOP didn't turn out to be all it was cracked up to be? Yup. Does this mean we're throwing the whole idea out? Nah, it's just evolving. The original idea's been augmented with other useful ideas like the interface segregation principle, the Liskov substitution principle (mixing behavior with data makes obeying LSP very difficult), and acknowledging the value of referential transparency.
  - gagege 8y ago
    What I always ask is, why use classes at all? I love that newer language docs like the ones for Kotlin and Swift are telling people to use structs and bare functions.
    - bunderbunder 8y ago
      To name one example: Because it still allows you to write to a higher level of abstraction. So you can have all sorts of different data storage classes - lists, sets, hash maps, etc. - and decide that they all implement an "enumerable" interface, and then any functions that just need to be able to apply some operation to every element in a collection can work with every single one of your collection types. Haskell has ways of getting us that sort of thing with only structs and bare functions - and does a really nice job of it, too - but most of us aren't working in Haskell.

yonixw 8y ago

I disagree with no.11 ... I prefer nested code of if's because as a reader I learn which conditions are relevant and assumed, rather than check-it-all at the start.

aw1621107 8y ago
How does checking at the start not convey what conditions are relevant and what assumptions can be made in the rest of the function?
wongarsu 8y ago
If I put all my early exits at the start, for the remainder of the function I only have to remember the list of preconditions established by the early exits. With deeply nested code I instead have to keep a stack of currently fulfilled conditions in mind. Sure, at any given point the stack is shorter than the list so there's less things to keep in mind, but for me dealing with mental lists is much easier than dealing with mental stacks.
ThorinJacobs 8y ago
What level of nesting are you referring to here? I ask because I experience the opposite - with more than one or two levels of nesting I have difficulty keeping track of the condition the block expects. Depending on the size of the method sometimes even one level can make me stumble a little.

de_watcher 8y ago

Number 14 is funny: it's like "do classes, but don't do what classes actually do". The first paragraph then goes about setters and getters that are specifics of some particular styles in some particular languages (and why you even need setters if you want to be clear about "not manipulating the data"?).

bunderbunder 8y ago
#14 fits into a fairly well-established trend of thought on object-oriented programming. A lot of us have noticed, over the 20-ish years since OOP really got popular, that doing it in the way most of us were taught in CS 101 (or wherever) tends to produce code that is difficult to maintain over time. In the particular case of mixing data storage and data manipulation in a single class: It tends to yield classes that continuously accumulate new functionality over time. They also tend to be difficult to refactor int a set of smaller classes. The level of impact on consuming code is very high, because splitting those classes tends to also force major changes to anything that interacts closely with them. And, since all that functionality lived inside a single class, it's likely to be internally resistant to change, too. It's really easy to treat "encapsulation" as a reason to not worry overmuch about shared use of glo^H^H^H instance variables. Does this kind of stuff mean that OOP didn't turn out to be all it was cracked up to be? Yup. Does this mean we're throwing the whole idea out? Nah, it's just evolving. The original idea's been augmented with other useful ideas like the interface segregation principle, the Liskov substitution principle (mixing behavior with data makes obeying LSP very difficult), and acknowledging the value of referential transparency.
- gagege 8y ago
  What I always ask is, why use classes at all? I love that newer language docs like the ones for Kotlin and Swift are telling people to use structs and bare functions.
  - bunderbunder 8y ago
    To name one example: Because it still allows you to write to a higher level of abstraction. So you can have all sorts of different data storage classes - lists, sets, hash maps, etc. - and decide that they all implement an "enumerable" interface, and then any functions that just need to be able to apply some operation to every element in a collection can work with every single one of your collection types. Haskell has ways of getting us that sort of thing with only structs and bare functions - and does a really nice job of it, too - but most of us aren't working in Haskell.