|
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!
|
|
|
|
|
|
As a native English-speaking developer, this conversation has been a fascinating insight into the world of non-native English-speaking developers! Thank you both. It also makes me grateful that I don't have to think about those kind of complexities, and gives me a new-found respect for the additional challengers you face.
I can't even imagine what it must be like for developers who don't even speak English as a second language.
PS I now have a little bit of umlaut envy
|
|
|
|
|
If one does not speak English, at least on software coding level, in Poland, s/he doesn't get far in this field. After all, most docs are in English, most tutorials are in English, most recent books are in English, and almost every professional is publishing in English first.
|
|
|
|
|
Quote: PS I now have a little bit of umlaut envy
|
|
|
|
|
You Europeans (and European-descended) have it so easy! 
Your languages are mostly descended from the same sources - Latin etc'.
What about us Right-to-Left Language users?
Having to translate to and from Hebrew is nearly 15% of my job...
Also, sometimes using readable variables and object names in this environment means naming them using a mash-up like "MenuSfiraMlay" for example, which translates to "StockTakingMenu".
The original developer here knew enough English to code, not enough to translate.
Which means that most related object use the same naming convention, to keep consistency and readability.
Also, sometimes I feel that some meanings are better expressed in Hebrew, especially when considering that future maintainers of this codebase will also be Native Hebrew speakers, with English sometimes being their third (!) language...
And I don't even want to think what it's like for Far-Eastern Language speakers..
|
|
|
|
|
Mike Barthold wrote: 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.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
