Unsolved code verbosity severely bugs my ADD and OCD
-
@jsulm said in code verbosity severely bugs my ADD and OCD:
it is more important to write understandable code than having short names.
+1
The ideal is to be "easy to read" and "easy to understand", not to be "verbose".
- Too short => Difficult to read
- Too long => Difficult to read
- Just right => Easy to read
@Kent-Dorfman said in code verbosity severely bugs my ADD and OCD:
a 30+ character variable or type name listed over and over again...often with a single word in the middle of it transposed to something else.
This sounds horribly difficult to read. I wouldn't want to work on such a code base
-
@JKSH said in code verbosity severely bugs my ADD and OCD:
Too short => Difficult to read
Too long => Difficult to read
Just right => Easy to readReminds me of "Goldilocks", "The Three Bears" and "porridge" :) Do you have this tale in Europe?
-
@JonB sure,
Goldlöckchen und die drei Bären
here in Germany, but we don't have the same phrase for a goldilocks zone resulting from the tale :D -
@JonB said in code verbosity severely bugs my ADD and OCD:
Do you have this tale in Europe?
It France it is called "Boucle d'Or et les trois oursons" ;)
AFAIK, it is a britisch/scottish fairy tale. -
@KroMignon said in code verbosity severely bugs my ADD and OCD:
AFAIK, it is a britisch/scottish fairy tale.
Well that might explain "porridge", I don't know whether you really eat that stuff in Germany/France but one certainly does in Scotland!
Having said that, I was under the impression that basically all fairy tales came from Europe (Germany/Eastern), I didn't think we really invented any here... :) (And I think it has been a long time since we have had any bears in the British Isles!)
-
@JonB said in code verbosity severely bugs my ADD and OCD:
it has been a long time since we have had any bears in the British Isles
Just wanted to ask that :-)
-
@jsulm
Our largest non-herbivore is basically the fox! :) -
@JonB said in code verbosity severely bugs my ADD and OCD:
Our largest non-herbivore is basically the fox! :)
Aha, this made me remember this: "The quick brown fox jumps over the lazy dog"
Often used to check communication protocols and/or display :D
-
@KroMignon
You do/Do you realise this phrase was chosen (I believe in typewriter days) as (just about the shortest, meaningful) sentence holding all 26 letters of the alphabet? -
@JonB said in code verbosity severely bugs my ADD and OCD:
You do/Do you realise this phrase was chosen (I believe in typewriter days) as (just about the shortest, meaningful) sentence holding all 26 letters of the alphabet?
Yes of course, this is why I used to check if all is working well ;)
But I must admit, this phrase was suggested by a British co-worker. It found it funny, so I used it often :) -
@Kent-Dorfman
I am sorry, it is probably I who have hijacked your thread! Hope you don't mind.Getting back to your original comment about the length of variable/symbol names. You might (or might not) be interested that when I started out in Unix System V.0 coding many years ago, at least external linker symbols (e.g. publicly visible global function names) were limited to 7 character significance! You could name a global function/variable with more characters if you wished, but they would be "chopped off" at the seventh character (actually to allow a maximum of 8 characters, because they would have an underscore character added at the beginning), and had to be distinct from any other global symbol within the first 7 characters, else clash error).
This led to severe required "abbreviation" of one's chosen function names! If you have ever wondered why C library functions had names like
strncpy
and not longer, this is the reason :)Just as a separate by-the-by, filenames (per directory) were limited to 14 characters, so that with an additional 2 bytes/16 bits of file attributes/permissions (like
drwxrwxrwx
) every file name fitted into a convenient 16 bytes in the file system... :) -
If the company I currently worked for, would actually enforce the coding guidelines, I would be forced to name stuff like:
uint16_t u16_input_status = 0
I think I suddenly would find myself doing much more functional programming.
-
You missed FORTRAN? It is so hard to maintain it. Actually, I hated it because of a lot of short names. Often it is painful to read someone else's code. And it introduced even class and this may kill itself. I am glad I switched to C++.
It is better to write code like a book. More readable, better to maintain it. I later realized that I should always think I am writing code for someone else, but for myself.
Who is writting a code alone nowadays?
.
-
I would then argue that the minions of mediocity have done well in convincing people to to think as marketers/writers intead of as engineers/mathematicians/scientists. Most of this same "identifers must be meaningful" drivvel is linked to code that severely lacks in internal inline documentation...as if somehow being wordy negates any responsibility to comment on what you're trying to accomplish...and as I stated before, pointy haired boss will be much more impressed with expressing a code idea in 1000 lines instead of 100. LOL
I mean why write this:
if (condition) { DoSomething(); } else { SomethingElse(); }
when you can make the reader scroll pages by doing:
if (condition) { DoSomething(); } else { SomethingElse(); }
-
@Kent-Dorfman Often bald bosses do not care how many lines are written and do not look at code at all. Instead they prefer to know what works and what not. The code is made for your co-workers. You may discuss a bit more with your accountant to know how much maintenance of your software costs. It is so true that some people do think they are engineers or whatever only for big things.
Actually I prefer the following
if (condition) { DoSomething(); } else { SomethingElse(); }
not because there are more lines. Simply it is easier to find the missing curly bracket if one of them is forgot. I made this in the coding standard of the company.
-
Not surprised that you prefer it...I wouldn't work in a company that enforces that waste of screen real-estate.
coding was once a creative art form where you tried to accomplish the most correct and the most elegant with the least effort...My how times have changed.
-
@Kent-Dorfman I don't see how writing inline comments instead of using meaningfull names is better? This approach does not reduce the amount of text you have to write. So, why not use meaningfull names to make the code readable and reduce the need to write comments which explain the code?
-
@JoeCFD said in code verbosity severely bugs my ADD and OCD:
Simply it is easier to find the missing curly bracket if one of them is forgot. I made this in the coding standard of the company.
is that a "recent" change? Because modern IDE's are excellent at discovering missing brackets and notifying you where you have to add them and even add the closing one automatically for you. So creating and finding missing brackets became mostly a thing of the past.
I'm with @Kent-Dorfman on this, I prefer opening brackets to be inline.
I also inlineinline
functions, getters and such.
On the other hand, I ALWAYS bracket my if body, even if it only 1 line. I'm sure Kent will disagree with me an this one ;) -
In Fortran you were forced to use short names (at least for subroutines/functions, but I believe also for variables). What added to the problem was the character limit per line coming from the use of punch cards. (Also, you could reduce the number of cards to carry around significantly by using shorter names.)
I have to work with old FORTRAN 77 source code occasionally. It is really hard to keep track of variable names inside subroutines of more than 1000 lines. Initially, most variables' intentions were commented. But, this strict discipline did not carry over into the new century. Not all variable names are commented. And also not all comments are correct.
@Kent-Dorfman wrote:
If you want to be verbose then do it in comments, not code...code does NOT replace proper use of inline commenting.
I'd say there is no proper use of inline commenting. Everything you have in code instead of comments needs to be kept up to date for it to compile. There is nothing forcing you to keep comments updated. Self-documenting code is much more helpful than comments. This does not mean that you should never write comments, but if you use them rarely people will know that they are important and need to be followed and updated if the code changes. I also don't like variable names which are too long, but I do hate names that are too short much more. The only exception is when names are used in short sections of code (e.g. variables named
tmp
to make it clear that they are used locally), as well asi
,j
, etc. for loops,ui
in Qt for the UI object generated by Qt Designer files, and the like. My collegue particularly likes copy&paste and will happily use long names as he will never type them. I am a fast typer and don't mind using longer names (and then there's also auto complete...). In large software you will read your own code a lot more often than you write it. Then it makes sense to make your code comprehensible, i.e. sufficiently verbose. (Though I advocate to make it not any more verbose than necessary.) -
@J-Hilk
To throw my own (doubtless-controversial) hat into the ring, I am a semi- @Kent-Dorfman :)I am a no-parentheses-around-single-statement programmer (
if
s,while
s,for
s, etc.). I just don't like a{
at the end of the line and the "wasted" line used for the closing}
after single-statements.OTOH, when multi-statement I always put the opening
{
on its own line below (yes, that could also count as a "wasted" line!). This has nothing to do what what IDEs can do in the way of showing parenthesised-pairs. Rather it is an aid I prefer when running my eyes down the code screen visually.But apparently unlike what he is saying I do try to pick meaningful names. I don't make them as-long-as-an-essay, but meaningful variable & function names avoid the need for many comments one might otherwise feel the need to put in. FWIW I am now trying to move away from end-of-line comments, preferring to put them on their own lines above the line they apply to.
On a separate but related note, I hate the way Python uses indentation for semantics, and then people paste their code (e.g. in this forum) without making the effort to Code-tag it, and then we can't see the indentation and they think that is fine...!