That's the Boy Scout's marching song
As through life you march along
Be prepared to hold your liquor pretty well
Don't write naughty words on walls if you can't spell
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Maybe it's just me, but I've never came across another dev's production code that had too many comments, a couple dumb ones, sure, but not an obscene amount. The exception is tutorial code that does have a massive amount of comments to help you learn something new, and not meant to ever go into production.
Most of the other dev's I've worked with in my career don't comment anything (unless it's commented code they don't need), and break all the other readable rules also. one dev didn't like variables or function names over 3 characters, most defaulting to 1 character when ever possible and reusing variables for other uses, another put the whole novel into a name: _ThisIsACountingVariableForTheIndexerFunction. Both were hard to read and understand what the code was actually doing.
Clean code principles.
Limit comments. Comments go stale and end up just being clutter.
Naming conventions should and everything with a custom name should be named to very clear on what the purpose.
Code should be READABLE
I met many of them (junior, mid and senior) that use git cli instead of a visual tool because "they don't need it" and the mess they do solving merge conflicts, etc, is really annoying!
It's a rule now for me: git cli => merge mess
Our codebase started 15 years ago and continues to expand. For the longest time I did 99% of the coding so the ~1M line codebase followed a set of standards, defined by me. As the team expanded I wrote a "developers guide" that included a detailed description of the standards. For some reason, we continue to have developers who just don't want to follow the rules. Fortunately I still do 90% of the coding so only certain pieces of the codebase are having issues. I am also the person who approves all pull requests into the master branch, which are going to start being more scrutinized for following the standards...
Had an individual working for me at one time that had his own "coding style". After writing his first module, I said to him "rewrite it in my style because I will around long after you're gone". He did--grumbling.
Did it a second time. I said rewrite it--without pay. He did.
I inherited a mess. The previous person would try something, hit a problem and then start over, leaving the old code and SQL tables around "just in case". I come in, and trying to troubleshoot is like walking in a maze where all the passages look alike. And who knows if that "unused" code is actually somewhere else, since he also liked to use code over and over (if it worked once, it should work in every scenario...until it didn't, in which case he abandoned that code and made a copy and fixed it for this one instance...) So, I have RunThis and RunThis2 and RunThisSometimes and RunThisOne and NO documentation (well, I'm working on it) about where these items are used (if anywhere). Argggggggggggggg...
THIS! We have such excellent source control systems these days, I absolutely DO NOT understand why anybody leaves dead code just lying around. I hate it just as much when people leave it in the form of large blocks of commented-out code. I totally get doing that kind of thing while you're workshopping a change or are in the middle of a big refactor, but please, PLEASE just keep that mess confined to your local working copy. I don't want to pull down the main branch and see all of that!
Premature optimizations are the worst of the lot.
Everything else I can (and have) handled, but optimizations before anything is properly released and measured.. that's just madness paving the way towards total insanity.
The compiler doesn't care, the users for sure don't care, management doesn't care, so it only exists to sooth the gigantic ego of the original author.
It signals to me that the lead architect or lead developer is a junior profile with no prior experience and way too much power.
I did live in such a world for a while. Not all the legacy code was lousy, but some of it was. Refactoring at that point would have been too slow, but the excellent automated testing capability made a rewrite possible. Strange, I know.
Far worse (IMO) than anything on that list is when a developer refuses to work with teammates and codes as if they are the only dev involved. Making major changes unilaterally, refusing to collaborate, avoiding peer reviews, etc. To make it worse, that attitude usually goes hand-in-hand with a toxic personality.
Last Visit: 31-Dec-99 19:00 Last Update: 26-Jan-22 11:25