Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Which code style do you prefer the most?
Date: Wed, 26 Feb 2025 21:01:20 +0100
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vpnrug$2mq8h$3@dont-email.me>
References: <vpkmq0$21php$1@dont-email.me> <vpl2k4$24fmt$1@dont-email.me>
 <20250225104754.267@kylheku.com> <zWovP.1403558$21T3.838698@fx18.iad>
 <vplf5d$26v09$1@dont-email.me> <874j0g2a8u.fsf@onesoftnet.eu.org>
 <vpn3l8$2ipsc$1@dont-email.me> <vpna6d$2jmv1$2@dont-email.me>
 <zgHvP.1648767$be92.1633891@fx16.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 26 Feb 2025 21:01:21 +0100 (CET)
Injection-Info: dont-email.me; posting-host="215b4d371573711d49e34cbf56289f66";
	logging-data="2844945"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/iySP5RBZ1NVTxjMDLcwGs3Bc0HNnVJMU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:aUY1PoFJsJxqBE58/YBxBsdlLno=
In-Reply-To: <zgHvP.1648767$be92.1633891@fx16.iad>
Content-Language: en-GB
Bytes: 3519

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...