11–20 of 127 posts
Over the past few years I have grown disillusioned by the seemingly hyper focus on clean code concept. It seems perfectly logical to have readable code. But the excess that we programmers do with the concept.
There's something deeply unnerving about ugly code, I don't think we can just say 'well it works'. I think we should maybe aspire to find a frame of reference for evaluating when to change and not. During development, I find iteration can be useful, i.e. when you have code that's 'hot in your mind' and can be re-worked. Another key that the article doesn't seem to reference is encapsulation. It's one of the most gold…
Sample: https://i.imgur.com/QUO48fn.png
It's good to have someone else looking at your work in established projects. Pair programming provides some value to overcome this problem.
Overcome your weakness, you'll become a better developer.
Naming stuff is not trivial and not a bikeshedding.
Then these guidelines should be followed, no need for long discussions during code reviews.
Variable name does not follow guidelines => Mark it as an issue, defer to the guidelines move on.
Over the past few years I have grown disillusioned by the seemingly hyper focus on clean code concept. It seems perfectly logical to have readable code. But the excess that we programmers do with the concept.
Elegant code is easily just as bad as spaghetti code. I can't even begin to quantify how many hours of my life were wasted because someone thought it was more important to make something elegant rather than understandable. I get that it's satisfying to make something that "makes sense" if you've built a mental model of the problem from the beginning, but if it's incomprehensible to others(without serious devotion to figuring out what is going on) then it might as well be crap in the first place. At least spaghetti code can be fairly easy to hack because there's usually lots of duplication and specialized code, making it straight forward to step through with a debugger and make a change without mysteriously borking the entire app. Elegant code, ironically, can be more flimsy because it's usually written assuming that the system stays perfect, and changes to the system reveal single points of failure.
Clean code can be written without necessarily going overboard with elegance to the point where it's not easy to understand. Even dirty code can be workable given documentation(can just be comments explaining what things do) and consistency.
Not all code is critical and intended to maintained forever. Everyone is not working at Google, Amazon etc. most code I write is not run daily by 1000s of users.
On the contrary, there's software written all the time that has a realistic lifetime of a few years before it's either replaced with a 3rd party alternative or rewritten by some disgruntled programmer. Deadlines and business priorities often mean that foregoing what most of us would tout as "best practices" actually makes sense. Some software is only used by 10 people at a time, and can be maintained by one or two engineers. It probably makes more sense for the engineers to choose what's best for them and the company over what most people would say are the right things to do. There are people I know who don't write tests for their software(something I don't know that I would ever do), but each piece of software they write is small and has a lifespan of a few years at most, and the advantage to removing barriers to development is that they can make changes very quickly and get things done.
Naming stuff is not trivial and not a bikeshedding.
Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus.
Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line.
More important than picking the perfect name:
- Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life through the code path. If bolt is not a great name you can change later.
- Being easy to remember and type. There's no point with TurningWheelThatGoesSqueak and having a TurningWheelThatGoesSquak and a TurningWheelThatGoesSquewk this will only make the developers go crazy. Simplify.
And yes bikeshedding is bad. I just find it too ironic that parent's username reminds me of the place that took bikeshedding to the extremes.
