In my experience, so many things were _not_ a good solution to the problem but merely the first thing that looked like it worked. This leaves a trail of garbage behind which it's unclear if it's safe to remove or not, which is a huge cognitive overhead for someone trying to make changes later on.
If something is there that's not going to be obvious in 6 months time please please document/comment it. Stop building mysterious fences!
That's right, but the advice is targeted at you when somebody's already left you a mystery fence. They should have done better and documented it, but they didn't and now you have to deal with it.
Indeed, a comment in code that indicate that a choice was probably not optimal and it was done in hurry would help the next developer to not assume to much intention when reading this part of code.
In my experience extremely abstracted code with inconsistent naming schemes and general data confusion is a sign of bad code. Add meta programming (outside of well documented libraries with simple ergonomics) to that list.
In 20 years if it smells like duck it's because the duck was trying to shoehorn functional programming paradigms into ruby by abusing the hell out of blocks, bad clever code is just bad code.
Comments
In my experience, so many things were _not_ a good solution to the problem but merely the first thing that looked like it worked. This leaves a trail of garbage behind which it's unclear if it's safe to remove or not, which is a huge cognitive overhead for someone trying to make changes later on.
If something is there that's not going to be obvious in 6 months time please please document/comment it. Stop building mysterious fences!
That's right, but the advice is targeted at you when somebody's already left you a mystery fence. They should have done better and documented it, but they didn't and now you have to deal with it.
Indeed, a comment in code that indicate that a choice was probably not optimal and it was done in hurry would help the next developer to not assume to much intention when reading this part of code.
Is this Chesterton's Garbage?
Chesterton's Roadside Picnic
I love this analogy.
Sometimes it's a perfectly good fence, sometimes it's an invisible spatial anomaly that turns people inside out.
¯\_(ツ)_/¯
In my experience extremely abstracted code with inconsistent naming schemes and general data confusion is a sign of bad code. Add meta programming (outside of well documented libraries with simple ergonomics) to that list.
In 20 years if it smells like duck it's because the duck was trying to shoehorn functional programming paradigms into ruby by abusing the hell out of blocks, bad clever code is just bad code.