[ale] ***UNCHECKED*** Re: Linux kernel

[Jon "maddog" Hall]

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.

Commenting like this:

SUM=FIVE+FOUR /* add the value of FIVE to FOUR and place into SUM */

really does not add much to understanding the code.

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.

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.

The VMS "C" compiler was a very efficient compiler, generating code that
typically worked 30% faster than the GNU "C" compilers of the day.
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.

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.

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.

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.

YMMV.

md



On Thu, Nov 16, 2023 at 10:51 AM DJPfulio--- via Ale <ale at ale.org> wrote:

> On 11/16/23 07:43, Jon "maddog" Hall via Ale wrote:
> >
> > I will say that comments DID have a real impact when compilers were
> > reading in source code on paper tape on an ASR-33 Teletype, but that
> > was the last time I even considered the issue oft compilation time
> > being slowed down by comments.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20231118/e27a6549/attachment.htm>