|
"I know why it is slow / not working - we need to change x, y and z"
How do you know - based on what instrumentation or metrics?
|
|
|
|
|
I could write a book about other bad habits, but it's already been done.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
IMO, right behind uncommented, obtuse code goes a plethora of one line functions that do the obvious:
int Add(int a, int b)
{
return a + b;
}
int x = Add(y, 1);
Absolutely unnecessary--unless a person is getting paid by lines of code produced.
|
|
|
|
|
|
🎶🎶🎶
Be prepared!
That's the Boy Scout's marching song
Be prepared!
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?
--Zachris Topelius
|
|
|
|
|
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
|
|
|
|
|
MichaelLuna wrote: Limit comments. Comments go stale and end up just being clutter.
Comment like you, yourself, will need to go back to that point and need a reminder of what's going on.
I also use an implicit comment with functions and blocks, for example:
function startsHere() {
} and done similarly for blocks of any type that have a { and }. No mystery where it begins and ends, and more importantly, when nested, where they begin and end.
Having observed most other code, at least around here, is not commented, I'd rather have too much to read than stopping and staring and finding external references and all that shyte the hard way.
| 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 |
|
|
|
|
|
We had rules change in the course of the life of a university. If a student had registered for studies before 1964, certain rules applied and the rules changed after September 1964. This was in 1971.
So, in my COBOL program, I had a logical variable which I named RegisteredBeforeSept1964.
My code then read:
If RegisteredBeforeSept1964
[code snippet]
Else
[code snippet]
I thought descriptive variable names made the code readable and even self-documenting.
|
|
|
|
|
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
|
|
|
|
|
1. Prefixing database columns with abbreviations denoting the table and application.
2. Adding database columns named Spare*, then using them for whatever.
|
|
|
|
|
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.
There wasn't a third time.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
