- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
You must log in or register to comment.
I’ve been rallying against clever code for years!
Sure, it makes you have less lines for your l33t code solutions, but in the real world, it sacrifices the maintainability of code that others will eventually work on.
Between a clever 1 line fix and maintainable 10 line fix, I’ll choose the 10 line every time.
As an extensive commenter, I completely agree.
I need to know wtf I was doing, making it convoluted to save a few lines is pointless.
It’s often a good idea to make the code itself very explicit through verbose function and variable names, rather than writing comments that could lead to inconsistencies between code and comments (by not updating the comments at the same time as the code) (see “Fallacious Comments” from the catalog)
Some of these mostly just someone’s opinion, and I don’t quite agree with all of them
Agreed. Every time somebody links this to “prove” or underline their argument, I roll my eyes. There are a lot of subjective things there and many that are actually valid code.
half of these will make your code better lmao
which half?
I’ll never tell
My code is exclusively Complicated Regular Expressions and it’s screaming fast.
I’m not going through every one, but null checks, vertical separation, status variables and binary operator in name, are all things that often make your code better and more readable
I feel like if one tried to follow all of these “rules” at all times nothing would get done, at all.
A code smell isn’t supposed to be automatically bad. A smell is an indication that something might be wrong. Sometimes using a smelly pattern is legitimately the only way to do something.
Apart from the fact that, as another commenter said, “smells” are not “rules”, I think most of these points come down to developing good habits, and ultimately save a lot of time in the long run by initially spending some time thinking about maintainability and preventing/limiting technical debt accumulation.
