|
Writing incoherent Git commit messages for code check-ins. I see a bunch of commits with messages like:
"a"
"Stuff"
"Reworked stuff"
|
|
|
|
|
at least they are checking in code, way too many dev's just let it sit on their machine and never sync or upload 6 months of changes and then leave
|
|
|
|
|
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.
|
|
|
|
|
Doodling around and hand it over to me to 'Fix the one small bug'
Not formatting the code (why add a hundred empty lines???)
Non-descriptive variable names (and dozens not used at all)
|
|
|
|
|
Other: not refactoring lousy code "because it works"
|
|
|
|
|
One definition of legacy code is "It works, but nobody knows how." That scares management away from ever allowing dev's to touch it - too much risk (at least in every shop I've worked at).
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
A decent suite of automated tests can really help with that.
But my point was more aimed at people who write lousy code and leave it that way. Once they move on, it does indeed get harder to "fix".
|
|
|
|
|
Greg Utas wrote: A decent suite of automated tests can really help with that.
In which world do you live? Lousy legacy code paired with a decent suite of automated tests...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
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.
|
|
|
|
|
in our shop, you actually cannot merge branch code into master without an approved Pull Request Review.
All the other items you listed will ensure the employee has a very short stay with us...very short stay.
acomputerdog wrote: Making major changes unilaterally
I actually think this would be grounds for dismissal at our shop, but not sure how that would happen as you can't do any development in our systems without a user story or bug, that has to go through PR review first.
|
|
|
|
|
Slacker007 wrote: acomputerdog wrote: Making major changes unilaterally
I actually think this would be grounds for dismissal at our shop, but not sure how that would happen as you can't do any development in our systems without a user story or bug, that has to go through PR review first.
Task: Relocate the submit button from the left to right side of the form.
Commit message: Refactored the UI from Old Framework to New Framework because New Framework right aligns buttons by default.
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?
--Zachris Topelius
|
|
|
|
|
Definition of 'unilaterally':
"used to indicate that something is done by only one person, group, or country involved in a situation, without the agreement of others."
my comment was based on the premise that someone was making a change without the agreement of others.
you like to bust my chops on a lot of my posts. I find that interesting.
|
|
|
|
|
Slacker007 wrote: you like to bust my chops on a lot of my posts. I find that interesting.
I vaguely recall you (someone else??????) saying something like this to me in the past.
I don't know what to say other than that you apparently write the sort of post that triggers my desire to reply frequently. CP's layout is such that the names associated with messages are shoved so far off to the right that they're normally out of my field of view and ignored by default.
I'm not actively targeting you because 99% of the time I'm unaware of whom I'm replying to. ¯\_(ツ)_/¯
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?
--Zachris Topelius
|
|
|
|
|
To me, the worst one I find in other people's code is the funky names - non-descriptive names for objects and variables and everything. I still see names like "A," "B," , etc.
|
|
|
|
|
I definitely agree with you unless certain alpha abbreviations have meaning within your codebase. For example, we have a defined set of entities within a part of our codebase. Each has a base entity with multiple versions for config management. We have a defined set of one- or two-char abbreviations we use for these...
- Platform and Platform Version = p and pv
- Emitter and Emitter Version = e and ev
- Site and Site Version = s and sv
- Type and Type Version = t and tv
- Class and Class Version = c and cv
Because of the defined use of "e" we use "ea" as the variable for EventArgs within event handlers.
|
|
|
|
|
Generally agree, though with a few exceptions: loop variables with very limited scope (i, j, and k - my Fortran roots are showing), caught exceptions, occasional very local temporary variables used for clarity.
|
|
|
|
|
Agile
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
with an emphasis on over-engineering and too many features that will never be used in a million lifetimes.
modified 28-Jun-21 9:35am.
|
|
|
|
|
But sometimes it's just good fun.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
And that's where the problem lies.
|
|
|
|
|
Not testing enough, I mean developer-level testing.
|
|
|
|
|
I don't design things to fail: the greenhouse I built for herself was more solid that the house it was bolted to; my shed it bolted to the breezeblocks supporting it, and those are concreted in.
Software should be the same: designed to work, not fail.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|