<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">Many people do not take the time to learn how to comment well. I prefer the technique of writing a block of comments above a block of code, using good variable names (thank heavens that the days of six-letter limitations on viables are long gone) and other techniques for letting future programmers know what you were thinking and what the code was doing.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">Commenting like this:<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">SUM=FIVE+FOUR /* add the value of FIVE to FOUR and place into SUM */<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">really does not add much to understanding the code.<br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">I also do not like code where many operations are put into one line because the programmer feels this is somehow "more efficient". Modern compilers will optimize those lines much better than the average programmer can, then optimize them again in the atom and object code generation phases.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">Note that I used the word "average programmer". Great programmers (Ken Thompson and Dennis Ritchie come to mind) could optimize the statements very well, but the compilers would probably do as good a job of it.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">The VMS "C" compiler was a very efficient compiler, generating code that typically worked 30% faster than the GNU "C" compilers of the day.</div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">The VMS "C" compiler first added ANSI "C" compatibility, then GNU "C" compatibility, then decided to re-compile the entire X11 Window System Server to see how much more efficient the X-server would run.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">The answer was "no more efficient". It did not run any faster and it used the same amount of CPU as the X-server programmed with the GNU compiler.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">The reason was that the engineers working on the X-server knew the GNU compiler so well that they wrote code that the VAX-C compilers would not be able to make more optimal.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">These days the GNU compilers (I am told) have become so good that it is hard for commercial "C" compilers to compete. And if they do compete in optimization, you still have the issue of minor differences in syntax and semantics that do not make the optimization differences worthwhile if you are targeting your code for different platforms.<br><br>YMMV.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">md<br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small"><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 16, 2023 at 10:51 AM DJPfulio--- via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/16/23 07:43, Jon "maddog" Hall via Ale wrote:<br>
> <br>
> I will say that comments DID have a real impact when compilers were<br>
> reading in source code on paper tape on an ASR-33 Teletype, but that<br>
> was the last time I even considered the issue oft compilation time<br>
> being slowed down by comments.<br>
<br>
I worked in a place where there were 3 comments for every line of code AND incorrect comments were considered a minor bug during formal code reviews (at least 4 people reviewed every line of code there) and sometimes 20+ people, depending on the subsystem and complexity. Remember walking into a review meeting with over 20 people for my code. Fortunately, as the programmer, I wasn't talking. A 3rd person would do the line-by-line explanation.<br>
<br>
Additionally, people were required to turn in their written review sheets BEFORE the meeting started as a way to ensure they didn't show up unprepared. Most of the time, the code wasn't all that complex, but sometimes the code had to diverge vastly from the requirements to meet machine limitation issues. Those were lively reviews.<br>
<br>
Humans get swayed by incorrect comments, but having correct comments are are not just restating the exact same thing that the code does **is** useful, especially for boundary condition statements.<br>
<br>
For Long term programs - those with lifespans that last decades, maintenance and maintainability will cost more than the original creation, especially if non-trivial features are added.<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>