4 ms·

This is kind of how I felt about the S in single responsibility of SOLID too. I wonder if there are any principles out there which are actually objective/measur

This is kind of how I felt about the S in single responsibility of SOLID too. I wonder if there are any principles out there which are actually objective/measurable.

vbezhenar 3y ago
There are plenty of code metrics. I'm not aware of any that I would recommend, though (other than basic ones like keep function LoC <= 50, keep indentation level <= 3). But if you're interested, you can research this topic. I saw tools for Java which measure those code metrics.
BulgarianIdiot 3y ago
The only objective rule in SOLID is L: "Objects of a superclass should be replaceable with objects of its subclasses without breaking the application." And when you decipher it, it literally means "all X should act like X", which is already obvious. I.e. if "Y extends X" then Y is also X, so Y should act like X. The other rules are so vague and subjective, that you can spin them any way around to prove someone's code sucks if you choose so. Which is ideal for selling people books & consultation services. And for Internet arguments.
- mejutoco 3y ago
  When possible, I prefer to do away with objects and have functions with types. X in, Y out.
  - diarrhea 3y ago
    A style I like as well, but methods are exactly that as well, only that `X` is implied, and there's a danger of abusing state (`f(X) -> Y` can and often is pure, whereas the entire point of methods is to be impure (modifying instance state)).
    - mejutoco 3y ago
      > methods are exactly that as well, only that Exactly, except for implicit types and modifying state, indeed. Those are the reasons why I prefer the above.
zelphirkalt 3y ago
Start with simple. Don't involve objects and classes and whatever, until there is a need for them and you can justify them. Don't use them because OOP. If your program or part of a program is fundamentally just a complex function, then write it as function(s).

This is kind of how I felt about the S in single responsibility of SOLID too. I wonder if there are any principles out there which are actually objective/measurable.

vbezhenar 3y ago

There are plenty of code metrics. I'm not aware of any that I would recommend, though (other than basic ones like keep function LoC <= 50, keep indentation level <= 3). But if you're interested, you can research this topic. I saw tools for Java which measure those code metrics.

BulgarianIdiot 3y ago

The only objective rule in SOLID is L: "Objects of a superclass should be replaceable with objects of its subclasses without breaking the application." And when you decipher it, it literally means "all X should act like X", which is already obvious. I.e. if "Y extends X" then Y is also X, so Y should act like X. The other rules are so vague and subjective, that you can spin them any way around to prove someone's code sucks if you choose so. Which is ideal for selling people books & consultation services. And for Internet arguments.

mejutoco 3y ago
When possible, I prefer to do away with objects and have functions with types. X in, Y out.
- diarrhea 3y ago
  A style I like as well, but methods are exactly that as well, only that `X` is implied, and there's a danger of abusing state (`f(X) -> Y` can and often is pure, whereas the entire point of methods is to be impure (modifying instance state)).
  - mejutoco 3y ago
    > methods are exactly that as well, only that Exactly, except for implicit types and modifying state, indeed. Those are the reasons why I prefer the above.

zelphirkalt 3y ago

Start with simple. Don't involve objects and classes and whatever, until there is a need for them and you can justify them. Don't use them because OOP. If your program or part of a program is fundamentally just a complex function, then write it as function(s).