You must log in or register to comment.
But it applies to features, not coding practices
I disagree. It applies to everything. I would argue it applies to SOLID most of all. I do not find SOLID principals to be good ones to follow most of the time. Situational they can be useful but I have seen so many projects that strictly follow SOLID that becomes an unmaintainable mess.
If you struggle to understand the SOLID principles or think they are too general, then I would suggest you follow my SOLID Training Wheels until you understand them better.
I hate this excuse. If the answer to the problem is you are just not doing it right then it is a terrible answer. But lets look at some of this advice:
Summary: 1 piece of code has 1 responsibility. The inverse: 1 responsibility of code has 1 piece of code
Training Wheels:
Follow the 10/100 Principle
Do not write methods over 10 lines
Do not write classes over 100 linesNo. Just no. Making everything as small as possible is exactly what is wrong with the single responsibility principal. I agree that everything should have one responsibility, but that responsibility might be complex and require a lot of code. Hiding the code behind other functions does not make it easier to read, only means you need to jump around a lot in order to understand what it is doing which IMO makes things harder to read. Every time I jump location it gets harder to remember where you came from or what the wider context is. Keeping related code together is more important then creating small function.
Just take a look at the stdlib of almost any mainstream language. Like the ArrayList in Java, or Vec in rust. These classes are thousands of lines long with many methods being 10-20 lines of code with some even longer then that. Is this code bad or hard to read? Not for what it is doing. And code like this is not atypical in stdlibs, you can jump to almost any class/struct in a language of your choice and see similarly structured code. And in all cases the classes represent one thing and its methods do one thing on that object regardless of how many lines of code they contain.
If you have to change a class that already breaks the 10/100 Principle:
take your code out of that class and put it in a new class first so the original class is smaller
Check-in this refactor without your new code
make your changes in the new class
Check-in your new codeIMO this breaks the single responsibility rule. If new code is mostly related to a single class then it should be added to that class as that is what the class is responsible for. Adding a new class for every bit of logic just splits up the responsibility and makes it far harder to find what is responsible for something.
I could go on about the rest of that training guide - which this whole post seems to be an advert for.
YAGNI, will ruin your code base if you apply it to how you code.
It applies just as much to how you code as to what you are coding. If you added every programming paradigm and principal to your code base it would be a unreadable mess. Not to mention impossible to do as loads of these conflict with each other.
Pick the right tools for the right job. Don’t blindly apply anything to every situation. There are times when the SOLID principals can help but there are also times where they make code worst. Instead always ask yourself if there is a simpler way you could be doing something and if when applying a principal if it actually made the code easier to read (ask someone else as well as it can be hard to tell yourself). Don’t be afraid to break a principal if it is not helping.
which this whole post seems to be an advert for
I got the exact same impression. Reminds me of the XYZ evangelists who only know XYZ, think it applies to every situation, and have little other experience.
Hiding the code behind other functions does not make it easier to read, only means you need to jump around a lot in order to understand what it is doing which IMO makes things harder to read.
Exactly. That’s my gripe with most JS and PHP frameworks, some people just don’t work that way. Thanks, now i have to grok 70% of the codebase to understand what i need to change to implement simple feature request X.
But on the other hand, limiting the scope of functions is a must. Superfunctions are a plague.
- AHA - Avoid Hasty Abstractions
- WET - Write Everything Twice
- DRY - Don’t Repeat Yourself
I don’t understand how one would equate YAGNI with writing everything half assed. Is this actually an issue?
There are whole frameworks like this around, yes.
The speed in the quality-cost-speed triangle refers to the speed of producing the widget/code. The execution speed would fall under quality.
You can still only pick 2.
Ooh. I like this a lot.
YAGNI is for what you code, not how you code.
With how you code, you are gonna need it:
- Quality – You are gonna need quality.
- Maintainability – You are gonna maintain it.
- Replaceability – You are gonna replace it.
- Testability – You are gonna test it
- Security – You are gonna need security.
No so much that YAGNI falls short, but more like “When YAGNI means ‘You Are Gonna Need It’”
