|
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!
|
|
|
|
|
I think what may have been meant is unnecessary use of too many patterns and layers.
|
|
|
|
|
that's what I got out of it also. solid code is one thing, the other is over use of patterns and layers.
I met a developer once who was in love with dependency injection, so simple calls to do anything usually had to travel through an average of 14 layers to get to the originating class instance, and just about every class was in it's own project to compile to it's own DLL, the amount of projects alone during runtime was pretty painful to debug. since none of the classes were late binding they all had to be loaded up, kind of canceling the point of breaking up a large project.
|
|
|
|
|
As with everything else, it's a question of money. Yes, it may be possible to write an office suite that has no bugs, but how long would it take, and what would the final cost to the consumer be?
Our bar for acceptable quality depends on the possible consequences of failures. For most home and office applications, people will trade lower quality for much lower price.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
And there's the problem: you get what you pay for.
And if you pay peanuts, you get monkeys.
The only thing they produce is cr@p - but they can thrown down a lot of it, and cheap!
"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!
|
|
|
|
|
First, pulling libraries/frameworks without any reason. That's the easiest way to increase the cost of a project needlessly, since it will require much more knowledge to be maintained, it will introduce dependencies from other suppliers...
Second, not commenting. Unless you have well written design documentation bundled with the code it's really "how to doom a project from the start" because noone else will maintain it in 6 months.
Prematurely optimizing, for those who work in embedded and come from ye olde days of manually chiseling the program bits on the ROMs with a tiny scalpel and powerful goggles. Making code unreadable for no reason at all, and oftentimes precluding actual optimization strategies with bad code.
5000 lines functions. I hate you and be thankful murder is illegal.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
You haven't seen the beautiful gems produced by my cow-orkers. They do everything of the items mentioned above. And add several more.
What about functions whose return type indicates succes vs. failure - in C# btw, not plain old C. Also setting a global string variable LastError in case of an exception (and discarding extra information like stack trace). Creating empty data structures to pass them to functions, in order to fill them there - instead of a return value. Duplicating code - why get information X about device Y from device Y when you can have that in your own configuration file, and do all consequent calculations on your own instead of getting that from Y?
All properties are publically writable, of course. Sometimes, they may be privately readable at the same time.
Never look up a programming pattern when some one knowing how to do things tells them - that polemic know-it-all smart-ass better shut up.
Ha! You are beginners only! 
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
It's a question of "polite code".
The options list in this question is just a list of "bad behavior" a dev should avoid.
Code must be readable, well documented where necessary, but not "documented because every method must have a comment block on top".
A method should fit on the screen. Not 5k, not even 1k, in best case not more than 50 lines of code in a single method. You can split that if think about it.
SOLID. A class (and each method) is responsible for ONE thing, not more, not less.
Polite code. Others shall have a chance to understand what's going on.
Readable, not crazy abbreviated method and member names ("customerID", not "cid"). No lone wolf code. Code for the swarm, for the herd.
Oh, and very important: Code must be ENGLISH. I don't want to see spanish or german or any other language in comments when looking up something at stack overflow. I speak german. I live in Austria, but coding is an english thing. Programming languages are "english". No need to force your brain into perma-translate mode between class/method names and the language syntax. I costs so much energy.
Well designed classes and methods allow us to write "kind of" english sentences when writing code.
if (customer.isLoggedIn()) logoutButton.setVisible(true); is easier to understand and read than
if (kunde.eingeloggt()) abmeldenKnopf.setVisible(true);
A dev gets tired 3 times faster if he/she is forced to "switch" languages all the time when reading/writing code. Think english when writing code. No matter what your native language is.
my 2 cent.
Cheers!
modified 28-Jun-21 0:41am.
|
|
|
|
|
Mike Barthold wrote: Programming languages are "english".
Do you also enjoy functions named "DataEdit" - because, after all, it's "Daten bearbeiten" in German...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
tbh, for my understanding "dataEdit" is in no way a valid function name.
I can't even imagine what the function is supposed to do. but "updateRecordInDatabase" *is* a valid function name and tells me anything I need to know.
If it's in some kind of a data class, say "CustomerData", then the method should be named "edit" or just "update", so you get good readable code, like "customerData.update()", which, again, tells you everything you need to know. That's polite code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
