While that's true readability, in my opinion, is less important than functionality and using what others call "Dangerous" code seems generally helpful to me. Now, I do realise how easy it is for someone else to not realise what is happening in your code, especially if you mix default statements, constructors, structures, and overload operators. But shouldn't the reader just examine the code judiciously? When writing any code(except python, ruby, and JS) I don't make a point to write readable code, but functional, concise, and efficient code. Though, I'll keep what you said in mind.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
I don't make a point to write readable code, but functional, concise, and efficient code.
That's a very bad attitude to have when writing code. Anything higher level than raw machine code or bytecode for a VM runtime is intended to be read by humans, not computers. It's the whole reason that everything from assembly code up exists. And if it takes longer for someone to understand what your code is doing than it takes them to read it twice, chances are they're not going to correctly understand exactly what it's doing (and even if they do, they've probably spent more time than they should have getting to that point). This becomes even more of a reality when dealing with people who are either new to programming or have overspecialized in a particular type of coding (which is unfortunately more common than it should be). Also consider yourself 10 years from now digging this up and trying to remember what it does (chances are you will not remember exactly how it worked, even if you're an expert in C++ by then). This is why coding style is important, but it's also why it's preferred to use the highest-level construct possible that doesn't make the code more ambiguous.
Circling back to the loop example, the following is indeed perfectly understandable to most people:
However, once it gets past a few lines, it becomes much harder to track what's going on because you have to find where that label is in the code without any obvious hints to help you. In contrast, the following exactly equivalent loop code is both more concise and can be much more easily followed when the loop body ends up being thousands of lines (not as unusual as it sounds):
do{do_something();}while(!check_something());
The do {...} while (...); approach is also preferred for two other reasons though:
Good editors let you jump directly to matching braces/parenthesis. With the do {...} while (...); construct, this trivializes finding the other end of the loop (provided of course that your braces are properly balanced). In contrast, for your goto approach, you can only easily find the starting point of a loop from the end, and even then it's not as easy unless you make the effort of having all your labels be unique within the file (not just within the function as the C++ standard requires).
Exceptional editors allow for code folding, letting you collapse (language defined) blocks of code into a single line so you can make more efficient use of screen space and not be distracted by code in scopes other than what you're working on. This works perfectly fine with the regular do {...} while (...); loop, but does not work at all with a manually constructed goto-based loop.
Okay... that was long as HELL. I get what you're saying but all the points you made are still opinion based, or incorrect. The reason why l different languages were developed was not really out of necessity to be readable than it is to be time efficient. People can't read 0's and 1's as quickly as english or any other language for that matter. Usage of the goto statement over and over, or over huge spans of code is just as inefficient as many different loops and if statements. An experienced developer would work around that. Yes, using the do... while loop is favoured, but that doesn't mean usage the goto statement is dangerous. The whole point of having multiple methods to achieve the same outcome is to allow for different styles. Suggesting that any coding style that reaches outside of the standard scope is a "very bad attitude" is just genuine stupidity. True, readability is recommended in more than one community, but code that is readable is often not optimized, and no offence to those who don't agree, but that's kind of the trump card of c++, optimization. Now before you start talking about how optimized code is more difficult to debug, I respect your opinion, but I just DON'T agree. If I take devil's advocate and look at it from your perspective, yes readability is important, yes there are other more readable methods in c++, yes it's easier for others if you use readable methods, AND YET there is still a HUGE thing you completely overlooked. COMMENTS, they are LITERALLY there for EXACTLY what we're talking about. READABILITY. Understanding the code someone writes is hella easier with comments. If you write ANY code with the intention to return to it down the road you should use comments. Your code DOESN'T even have to be a little bit readable, if you put comments at every stage in your code you will be refreshed enough to understand what is going on, and a third party would too. I've said all I have to say, good day.
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Although I'm not the original commenter, I'll try to add my 2 cents and be as constructive as possible. Not sure if anyone will read it... but I'll take my chances.
Since you describe yourself as a student, that might explain your reaction, but I advise that you show more humility and civility. Austin S. Hemmelgarn made a comment in good faith without attacking and insulting you, yet you came back rather aggressively. There's no need for that. Especially because he made very clear points, which are (contrary to your statement) facts, not opinions. Your arguments, on the other hand, mostly don't make any sense. Let's see them.
"The reason why l different languages were developed was not really out of necessity to be readable than it is to be time efficient."
Actually, they were created out of necessity, at least quite a few. See the history of UNIX and why C was created (hint: its predecessor, B was not good enough).
Languages are created for different reasons: some want to abstract away the entire OS & HW layer and offer features that enables you to produce code quickly, without having to deal with memory management and potentially unsafe memory accesses. Some want to be domain-specific. Some want to be generic purpose but minimalist. Some languages are inherently more easier to comprehend than others. However, this has nothing to do with how you structure your own code and how you use certain language features. Just because something is possible, doesn't mean it's recommended to do on a regular basis.
"Usage of the goto statement over and over, or over huge spans of code is just as inefficient as many different loops and if statements."
I can't make sense of this statement, no matter how hard I try to interpret it.
Firstly, from the point of view of the CPU, there aren't even for or while loops. The CPU only sees conditional and unconditional jumps.
Secondly, why would using gotos or loops be inefficient if that's the way you achieve the expected behavior?
Sure, jumping unnecessarily back and forth or creating unnecessary, nested control flow is not efficient, but that's pretty obvious, so what are you trying to say here?
"Yes, using the do... while loop is favoured, but that doesn't mean usage the goto statement is dangerous"
No one said the goto statement is dangerous, but it is a poor practice in general. In your post, you said "Like looping on a condition, I can just use a label and call the goto statement. If I'd known that this is what I'd be doing I would've tried C++ a long time ago.". Maybe this isn't what you meant, but this sounds like the reason you hadn't tried C++ before is because you had thought it lacked goto?? In other words, it implies that you generally prefer goto to loop constructs, which is a BIG no in structured/OOP programming. The very reason structured programming was created is to avoid goto and spaghetti code (among other things).
"The whole point of having multiple methods to achieve the same outcome is to allow for different styles. Suggesting that any coding style that reaches outside of the standard scope is a "very bad attitude" is just genuine stupidity."
Yes, and using goto all the time is an extremely poor style! Its usage has to be justified. Indeed, there are cases when that's the right to do, but that's few and far between. Doing it constantly means that you completely disregard or you are oblivious to very basic software engineering principles. Neither option is particularly comforting. So I have to say that Austin is right, it's definitely a very bad attitude. Not every coding style is equal, so quite frankly, that "genuine stupidity" remark is really embarrassing.
"True, readability is recommended in more than one community, but code that is readable is often not optimized, and no offence to those who don't agree, but that's kind of the trump card of c++, optimization."
This is total nonsense. "Optimized" is very vague to begin with, depending on the context, such code can be perfectly readable. Sure, if you opt to use inline assembly or compiler intrinsics to utilize SSE/AVX extensions, then it might complicate things, but that means that the problem domain is likely already complex.
"COMMENTS, they are LITERALLY there for EXACTLY what we're talking about. READABILITY. Understanding the code someone writes is hella easier with comments. If you write ANY code with the intention to return to it down the road you should use comments. Your code DOESN'T even have to be a little bit readable, if you put comments at every stage in your code you will be refreshed enough to understand what is going on, and a third party would too"
And here it is, the most brutal. This line of thinking is not just fatally flawed, but also bloated with incredible arrogance. It's important to hear me out: as a SW developer for >10 years, I can honestly tell you, saying this during a job interview would instantly disqualify you! At least, if you were to utter these words to me with the tone you're using here, I'd probably end the interview on the spot. I'm not joking. It perfectly demonstrates that you have little to no understanding of how important code readability is in real life projects - which is part of the basic software craftmanship. Vast ignorance combined with combative stance and arrogance - a recipe for disaster.
So listen:
Comments ARE NOT SUBSTITUTE FOR well-written code! What do you modify if changes are needed? The comment or the code? Well, actually it's both and that's a big problem! Now, if it's a goddamn mess, how will you do it? Spend 30 minutes on figuring out what it does by constantly re-reading the comment, make the change, THEN adjust the comment? How about writing expressive, idiomatic, maintainable code WITHOUT comments and adding the change in 5 minutes? Which one do you think it's better? So yes, the code HAS to be readable (to the best of your abilities)! No exceptions, no "but". You must understand the gravity of what I've just said.
I sincerely hope my comment helped and you can get something out of it.
I think it's kinda silly how they believe comments are supposed to describe your code in depth, line by line. That would be a hodgepodge mess of comments! All Comments would be useless if the person viewing your code can't connect the contents of the comment to the contents of the code!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While that's true readability, in my opinion, is less important than functionality and using what others call "Dangerous" code seems generally helpful to me. Now, I do realise how easy it is for someone else to not realise what is happening in your code, especially if you mix default statements, constructors, structures, and overload operators. But shouldn't the reader just examine the code judiciously? When writing any code(except python, ruby, and JS) I don't make a point to write readable code, but functional, concise, and efficient code. Though, I'll keep what you said in mind.
That's a very bad attitude to have when writing code. Anything higher level than raw machine code or bytecode for a VM runtime is intended to be read by humans, not computers. It's the whole reason that everything from assembly code up exists. And if it takes longer for someone to understand what your code is doing than it takes them to read it twice, chances are they're not going to correctly understand exactly what it's doing (and even if they do, they've probably spent more time than they should have getting to that point). This becomes even more of a reality when dealing with people who are either new to programming or have overspecialized in a particular type of coding (which is unfortunately more common than it should be). Also consider yourself 10 years from now digging this up and trying to remember what it does (chances are you will not remember exactly how it worked, even if you're an expert in C++ by then). This is why coding style is important, but it's also why it's preferred to use the highest-level construct possible that doesn't make the code more ambiguous.
Circling back to the loop example, the following is indeed perfectly understandable to most people:
However, once it gets past a few lines, it becomes much harder to track what's going on because you have to find where that label is in the code without any obvious hints to help you. In contrast, the following exactly equivalent loop code is both more concise and can be much more easily followed when the loop body ends up being thousands of lines (not as unusual as it sounds):
The
do {...} while (...);approach is also preferred for two other reasons though:do {...} while (...);construct, this trivializes finding the other end of the loop (provided of course that your braces are properly balanced). In contrast, for yourgotoapproach, you can only easily find the starting point of a loop from the end, and even then it's not as easy unless you make the effort of having all your labels be unique within the file (not just within the function as the C++ standard requires).do {...} while (...);loop, but does not work at all with a manually constructedgoto-based loop.Okay... that was long as HELL. I get what you're saying but all the points you made are still opinion based, or incorrect. The reason why l different languages were developed was not really out of necessity to be readable than it is to be time efficient. People can't read 0's and 1's as quickly as english or any other language for that matter. Usage of the goto statement over and over, or over huge spans of code is just as inefficient as many different loops and if statements. An experienced developer would work around that. Yes, using the do... while loop is favoured, but that doesn't mean usage the goto statement is dangerous. The whole point of having multiple methods to achieve the same outcome is to allow for different styles. Suggesting that any coding style that reaches outside of the standard scope is a "very bad attitude" is just genuine stupidity. True, readability is recommended in more than one community, but code that is readable is often not optimized, and no offence to those who don't agree, but that's kind of the trump card of c++, optimization. Now before you start talking about how optimized code is more difficult to debug, I respect your opinion, but I just DON'T agree. If I take devil's advocate and look at it from your perspective, yes readability is important, yes there are other more readable methods in c++, yes it's easier for others if you use readable methods, AND YET there is still a HUGE thing you completely overlooked. COMMENTS, they are LITERALLY there for EXACTLY what we're talking about. READABILITY. Understanding the code someone writes is hella easier with comments. If you write ANY code with the intention to return to it down the road you should use comments. Your code DOESN'T even have to be a little bit readable, if you put comments at every stage in your code you will be refreshed enough to understand what is going on, and a third party would too. I've said all I have to say, good day.
you're not very bright, are you
Although I'm not the original commenter, I'll try to add my 2 cents and be as constructive as possible. Not sure if anyone will read it... but I'll take my chances.
Since you describe yourself as a student, that might explain your reaction, but I advise that you show more humility and civility. Austin S. Hemmelgarn made a comment in good faith without attacking and insulting you, yet you came back rather aggressively. There's no need for that. Especially because he made very clear points, which are (contrary to your statement) facts, not opinions. Your arguments, on the other hand, mostly don't make any sense. Let's see them.
"The reason why l different languages were developed was not really out of necessity to be readable than it is to be time efficient."
Actually, they were created out of necessity, at least quite a few. See the history of UNIX and why C was created (hint: its predecessor, B was not good enough).
Languages are created for different reasons: some want to abstract away the entire OS & HW layer and offer features that enables you to produce code quickly, without having to deal with memory management and potentially unsafe memory accesses. Some want to be domain-specific. Some want to be generic purpose but minimalist. Some languages are inherently more easier to comprehend than others. However, this has nothing to do with how you structure your own code and how you use certain language features. Just because something is possible, doesn't mean it's recommended to do on a regular basis.
"Usage of the goto statement over and over, or over huge spans of code is just as inefficient as many different loops and if statements."
I can't make sense of this statement, no matter how hard I try to interpret it.
Firstly, from the point of view of the CPU, there aren't even for or while loops. The CPU only sees conditional and unconditional jumps.
Secondly, why would using gotos or loops be inefficient if that's the way you achieve the expected behavior?
Sure, jumping unnecessarily back and forth or creating unnecessary, nested control flow is not efficient, but that's pretty obvious, so what are you trying to say here?
"Yes, using the do... while loop is favoured, but that doesn't mean usage the goto statement is dangerous"
No one said the goto statement is dangerous, but it is a poor practice in general. In your post, you said "Like looping on a condition, I can just use a label and call the goto statement. If I'd known that this is what I'd be doing I would've tried C++ a long time ago.". Maybe this isn't what you meant, but this sounds like the reason you hadn't tried C++ before is because you had thought it lacked goto?? In other words, it implies that you generally prefer goto to loop constructs, which is a BIG no in structured/OOP programming. The very reason structured programming was created is to avoid goto and spaghetti code (among other things).
"The whole point of having multiple methods to achieve the same outcome is to allow for different styles. Suggesting that any coding style that reaches outside of the standard scope is a "very bad attitude" is just genuine stupidity."
Yes, and using goto all the time is an extremely poor style! Its usage has to be justified. Indeed, there are cases when that's the right to do, but that's few and far between. Doing it constantly means that you completely disregard or you are oblivious to very basic software engineering principles. Neither option is particularly comforting. So I have to say that Austin is right, it's definitely a very bad attitude. Not every coding style is equal, so quite frankly, that "genuine stupidity" remark is really embarrassing.
"True, readability is recommended in more than one community, but code that is readable is often not optimized, and no offence to those who don't agree, but that's kind of the trump card of c++, optimization."
This is total nonsense. "Optimized" is very vague to begin with, depending on the context, such code can be perfectly readable. Sure, if you opt to use inline assembly or compiler intrinsics to utilize SSE/AVX extensions, then it might complicate things, but that means that the problem domain is likely already complex.
"COMMENTS, they are LITERALLY there for EXACTLY what we're talking about. READABILITY. Understanding the code someone writes is hella easier with comments. If you write ANY code with the intention to return to it down the road you should use comments. Your code DOESN'T even have to be a little bit readable, if you put comments at every stage in your code you will be refreshed enough to understand what is going on, and a third party would too"
And here it is, the most brutal. This line of thinking is not just fatally flawed, but also bloated with incredible arrogance. It's important to hear me out: as a SW developer for >10 years, I can honestly tell you, saying this during a job interview would instantly disqualify you! At least, if you were to utter these words to me with the tone you're using here, I'd probably end the interview on the spot. I'm not joking. It perfectly demonstrates that you have little to no understanding of how important code readability is in real life projects - which is part of the basic software craftmanship. Vast ignorance combined with combative stance and arrogance - a recipe for disaster.
So listen:
Comments ARE NOT SUBSTITUTE FOR well-written code! What do you modify if changes are needed? The comment or the code? Well, actually it's both and that's a big problem! Now, if it's a goddamn mess, how will you do it? Spend 30 minutes on figuring out what it does by constantly re-reading the comment, make the change, THEN adjust the comment? How about writing expressive, idiomatic, maintainable code WITHOUT comments and adding the change in 5 minutes? Which one do you think it's better? So yes, the code HAS to be readable (to the best of your abilities)! No exceptions, no "but". You must understand the gravity of what I've just said.
I sincerely hope my comment helped and you can get something out of it.
I think it's kinda silly how they believe comments are supposed to describe your code in depth, line by line. That would be a hodgepodge mess of comments! All Comments would be useless if the person viewing your code can't connect the contents of the comment to the contents of the code!