Deutsch   English   Français   Italiano  
<val6u3$33e82$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Python (was Re: I did not inhale)
Date: Tue, 27 Aug 2024 20:46:27 +0200
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <val6u3$33e82$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <v9m4gd$14scu$1@dont-email.me>
 <20240815182717.189@kylheku.com> <v9npls$1fjus$1@dont-email.me>
 <v9t204$2dofg$1@dont-email.me> <va28pi$3dldm$1@dont-email.me>
 <va2ro9$3gd7v$1@dont-email.me> <va2vt0$3h3gj$1@dont-email.me>
 <va44rh$3p1l6$1@dont-email.me> <va45eq$3pkt9$1@dont-email.me>
 <va4aut$3q4g0$1@dont-email.me> <va4fbr$3qvij$1@dont-email.me>
 <va5108$3tmmd$1@dont-email.me> <va51ok$3tqr9$1@dont-email.me>
 <va5ec2$3vluh$1@dont-email.me> <va6q4g$c1a7$1@dont-email.me>
 <va6rpa$c6bg$1@dont-email.me> <va6se9$cb8e$1@dont-email.me>
 <20240826083330.00004760@gmail.com> <vaises$2k7o6$2@dont-email.me>
 <20240826155113.000005ba@gmail.com> <wwvo75eicla.fsf@LkoBDZeT.terraraq.uk>
 <vak9k9$2ujrs$1@dont-email.me> <vakj7g$303sh$1@dont-email.me>
 <20240827080320.00003fd2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 27 Aug 2024 20:46:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8355d15901bc9a80f13d9e1f7352f9f2";
	logging-data="3258626"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+EAX83JW+oMWuDEsUYjwXoNpvn490h8m0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4izAsHW0hAnsJmUfFMTJEg7XPAo=
In-Reply-To: <20240827080320.00003fd2@gmail.com>
Content-Language: en-GB
Bytes: 3893

On 27/08/2024 17:03, John Ames wrote:
> On Tue, 27 Aug 2024 15:10:08 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> 
>>> (6) You want to add extra statements to the end of a block, but
>>> where IS the end? You have to INFER the ending by looking for a
>>> line with a smaller indent. But suppose you're at the bottom of a
>>> window; is that bottom line the last in the block, or is there
>>> another one at the same indent just out of sight? You have to
>>> tentatively keep peeking ahead!
>>
>> Keep your blocks small and neat.
> 
> That's very much one for the "good advice that is not always feasible
> in the Real World" file. Every project has its own natural balance of
> "large things that can be easily re-factored into sets of small things"
> (i.e. things you can function-ize) vs. "large things that cannot."
> 

Sure.  But if you keep such advice at hand, then it is often easier to 
make it feasible.  Occasionally code is best formatted with a big 
function or two, but most of the time it is possible and preferable to 
have relatively small function.

>>> (6a) And maybe there's big comment blocking in the middle of block;
>>> comments don't need nesting! If there are lots of comments and few
>>> statements, finding the end of the block (ie. the last statement of
>>> this block) can become quite an exercise.
>>
>> That applies to every programming language (unless you know of one
>> that doesn't support comments).
> 
> It applies very much moreso to languages where comments *must* follow
> the indentation level of the surrounding code, so that the deeper you
> go, the more lines you have to split comments across.
> 

It is not common to have to have indent comment lines (certainly in 
Python it is not necessary).  And if you find yourself writing large 
comments in the middle of a block in the middle of a function, it is 
probably time to consider re-organising the code and/or the comments and 
documentation.  (Again, there can be exceptions to this general rule.)