4 ms·

What CRISP is supposed to mean: Correct Readable Idiomatic Simple Performant Notice that all this is just well-wishing and suitably vague, so that you fee

What CRISP is supposed to mean: Correct Readable Idiomatic Simple Performant Notice that all this is just well-wishing and suitably vague, so that you feel the need to buy a book & hire a consultant to explain it to you. The trick is there's nothing to explain.

MoreQARespect 4y ago
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 4y 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 4y 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 4y ago
    When possible, I prefer to do away with objects and have functions with types. X in, Y out.
    - diarrhea 4y 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 4y 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 4y 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).
commandlinefan 4y ago
> well-wishing and suitably vague That way, no matter what you do, they can say you did it wrong, and no matter what they do, they can say it's right.
mekoka 4y ago
It makes sense if you read the article. Correct: the primary objective. Code that does what it's supposed to, bug free. Readable: strive to write code that will be understandable by others (and your future self). Review what you wrote and be your own critic when it comes to clarity. Idiomatic: Write code the way people in your community expect to read. Don't surprise them with your own quirky and clever conventions, when there are well established and perfectly acceptable ones already. Simple: Your code should do what it says it does directly, with no funky side-effects. Repetition is not always a sin, don't DRY things up just for the sake of it. Don't do too many things. Be parsimonious. Performant: be aware of RAM (a bit of a letdown). The last point was disappointing, as I was expecting something about coding to data structures when it matters. Instead the author went on about being aware of memory.

MoreQARespect 4y ago

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 4y 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 4y 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 4y ago
  When possible, I prefer to do away with objects and have functions with types. X in, Y out.
  - diarrhea 4y 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 4y 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 4y 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).

commandlinefan 4y ago

> well-wishing and suitably vague That way, no matter what you do, they can say you did it wrong, and no matter what they do, they can say it's right.

mekoka 4y ago

It makes sense if you read the article. Correct: the primary objective. Code that does what it's supposed to, bug free. Readable: strive to write code that will be understandable by others (and your future self). Review what you wrote and be your own critic when it comes to clarity. Idiomatic: Write code the way people in your community expect to read. Don't surprise them with your own quirky and clever conventions, when there are well established and perfectly acceptable ones already. Simple: Your code should do what it says it does directly, with no funky side-effects. Repetition is not always a sin, don't DRY things up just for the sake of it. Don't do too many things. Be parsimonious. Performant: be aware of RAM (a bit of a letdown). The last point was disappointing, as I was expecting something about coding to data structures when it matters. Instead the author went on about being aware of memory.