code verbosity severely bugs my ADD and OCD
-
to be honest, I like to read my code as a text/novel from left to right, so you understand exactly what is happening while reading it
take this function for example
void resendPendingDatagram() { if(retryCount() < maxNumberOfRetries()){ setRetryCount(retryCount() +1); m_pendingDatagram.clearResponseBuffer(); sendDatagram(m_pendingDatagram); } else { stopTimeouts(); setError(tr("All retries exhausted"), MceDiscardedDatagram); } }obviously very verbose naming of members and functions. but just from reading left to right top to bottom spelling symbols out, you get a comprehensive description of what is happening.
If the retry count is less then the max number of retries*, then* increase the retry count by one, clear the response buffer and resend the pending datagram
else (if not) stop the timeouts and set an errorObviously its not perfect, but I try :D
And in my opinion, much clearer than
auto ptr,int count, i, m_data etcobviously I agree, that
ApActiveAvionicsDisplayPowerand similar is not that helpful as a name@J-Hilk Yes, I also like names for variables, methods and classes which tell you what it is about. There is no problem to use short names in some cases (like "i" in a for loop), but else it is better to write easy to understand code. Code is read more often than written, so it is more important to write understandable code than having short names.
-
@J-Hilk Yes, I also like names for variables, methods and classes which tell you what it is about. There is no problem to use short names in some cases (like "i" in a for loop), but else it is better to write easy to understand code. Code is read more often than written, so it is more important to write understandable code than having short names.
@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
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@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?
-
@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?
-
@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 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.It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)
-
@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!)
-
@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 :-)
-
@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 :-)
-
@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
It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)
-
@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
strncpyand 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 = 0I 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(); } -
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.
-
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?
-
@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.
@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 inlineinlinefunctions, 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 ;)
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
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
tmpto make it clear that they are used locally), as well asi,j, etc. for loops,uiin 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.)
