|
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.
|
|
|
|
|
Mike Barthold wrote: Oh, and very important: Code must be ENGLISH. I used to agree with you, but translating almost every specialized and/or made up jargon word my Dutch customers throw at me gets really tiring too.
At one point in my career I translated "mestland" to manure country.
I knew it wasn't correct, but at that moment I couldn't find what it was supposed to be and I was in a hurry to ship.
Turned out to be fattening country.
"Mest" can be both manure and fattening in Dutch, so that's how.
Also, when a customer calls me and says "I got a problem with mestland!" I don't want to think "mestland... how would I have translated that?"
Even worse when you're in a team and you have to think "how would my coworker have translated that?"
Became a real problem with a customer in the past.
You could keep a list with words and translations, but that would only add more work and still make communication to the customer more difficult.
So since then I'm just using whatever the customer is using.
|
|
|
|
|
Hi Sander,
I am not sure, whether we are talking about the same type of translation here... "mestland" sounds to me like a word the user sees on screen while using the application. That's not what I meant.
I meant classes, methods, members should be named in english. The user shall see everything in his/her language (or the desired language)
|
|
|
|
|
Yeah, I know what you meant.
Our users saw "mestland", of course.
But our software and database were full of "ManureCountry" (as DB column, property, variable, etc.) because no one knew the exact translation, so we want for a literal translation.
Our customer only wanted Dutch software, so they didn't give us translations and we really only did it for ourselves.
That software probably uses both FatteningCountry and ManureCountry now, as they found the correct translation later.
My current software looks a bit weird, with stuff like "GetMestland" or "UpdateMestland" (well, I'm not dealing with mestland anymore, but you get the gist).
It's half Dutch, half English, because as you said, programming languages and terms are English.
GetMestland sure as hell beats GetManureCountry though.
And if a customer calls me about mestland I immediately know what they're talking about.
I totally get why you'd do everything in English (easier to find (offshore) programmers too), but I've switched to the language of my customers.
That said, I still have Controllers, Views and Factories, and not Controleurs (or perhaps Opzichters?), Uitzichten/Aanblikken(I genuinely have no idea how to translate this, even with Google Translate) and Fabrieken, that would be weird
This is probably an issue for every non-English team with non-English customers: Ubiquitous Language in a non-english domain — webfactory GmbH[^]
But as an Austrian you've probably had this discussion too in the past
To all English speakers reading this, you're lucky your language was chosen as the #1 language in the world that all others should adjust to!
|
|
|
|
|