Sujet : Re: Which code style do you prefer the most?
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.cDate : 26. Feb 2025, 21:01:20
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vpnrug$2mq8h$3@dont-email.me>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Mozilla Thunderbird
On 26/02/2025 17:26, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 26/02/2025 14:06, Janis Papanagnou wrote:
On 26.02.2025 12:53, Ar Rakin wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
This is a good reason for preferring // comments to /* */ comments -
every line that is commented-out is clearly a commented-out line, and
doesn't need the context.
I disagree with this. A line of code should never be commented out;
simply removed if not necessary. The next maintainer of the code
five years down the line will have no idea why the commented out line
of code was kept in the codebase.
That's not unreasonable in the ideal situation. A lot of coding is not ideal, and things get commented out temporarily - and not tied up as it should be. I agree with the principle that code should be either present and useful, or not present at all - but practice does not always match principle.
But consider a case of some documentation:
// This function should be called like this:
//
// int x = foo(1, 2, 3);
//
// The returned value x will be the foo of the arguments.
There /are/ legitimate reasons for comments that at least appear to be code.
Conditional compilation (#if) with appropriate inline documentation
describing _why_ it was left in the codebase, would be acceptable;
but generally I don't like conditional compilation for readability
and maintainability reasons.
I've seen codebases where every fourth line was a #if, and the
code was almost impossible to follow or maintain.
I agree - conditional compilation can be useful, but it is best kept to a minimum or tidied away in one place.
It is also an argument against writing code like :
>
if (flag)
doThis();
>
Not only is adding a "doThat();" error-prone in itself (forgetting to
add braces is a real risk), but it means adding (or later removing) a
single line is now a three-line change.
Agreed. And for those of us old enough, the lack of braces means
that the 'if (flag)' line may need to be repunched to add the opening
brace later...