🚀 go-pugleaf

J. Clarke <jclarke...@gmail.com> wrote:
> On 26 Feb 2018 11:32:49 GMT, Jorgen Grahn <grahn...@snipabacken.se>
> wrote:
> 
>> On Mon, 2018-02-26, J  Clarke wrote:
>>> On 26 Feb 2018 06:43:24 GMT, Jorgen Grahn <grahn...@snipabacken.se>
>>> wrote:
>>> 
>>>> On Mon, 2018-02-26, Dan Espen wrote:
>>>>> Peter Flass <peter...@yahoo.com> writes:
>>>>> 
>>>>>> Bob Eager <news...@eager.cx> wrote:
>>>>>>> On Sun, 25 Feb 2018 17:29:16 +0000, Huge wrote:
>>>>>>> 
>>>>>>>> On 2018-02-25, Andrew Swallow <am.sw...@btinternet.com> wrote:
>>>>>>>> 
>>>>>>>> [15 lines snipped]
>>>>>>>> 
>>>>>>>>> Reading Fortran and Assembler code tells you how, it does not tell you
>>>>>>>>> why. Comments are needed for that.
>>>>>>>> 
>>>>>>>> *applause*
>>>>>>>> 
>>>>>>>> Anyone who writes code like this should be shot;
>>>>>>>> 
>>>>>>>> x=5;		# Set x to 5
>>>>>>> 
>>>>>>> Strangely, I was doing generic feedback for an assignment about an hour 
>>>>>>> ago. I repeated this statement, but not in Huge terms. (the external 
>>>>>>> examiner will read it)
>>>>>> 
>>>>>> When you start writing assembler everyone says you should put a comment on
>>>>>> every line, so you tend to do a lot of this until you get the  idea.
>>>>> 
>>>>> Putting a comment on every line makes it simpler to
>>>>> read the whole program as comments.  With highlighting
>>>>> this is an easy way to quickly absorb a module.
>>>>> 
>>>>> Of course the comments may not be 100% right.
>>>>> 
>>>>> In the above case, the code still needs a comment
>>>>> but it should be something like:
>>>>> 
>>>>> x=5;		# Max supported fingers
>>>> 
>>>> max_supported_fingers=5;  # Nothing more to say
>>> 
>>> But a lot more to type and that style tends to be hard to
>>> read--operators get lost in the visual noise.
>> 
>> A lot more to type, but a lot less to remember.  I agree that the
>> visual noise aspect is a problem, though.
>> 
>> It depends on the context.  For very local variables I tend to favor
>> one-letter names like i (for iteration), p, q (pointers), n and m
>> (quantities and sizes).
> 
> I used to do that but realized that it's a bad habit for a variety of
> reasons.  (Working in insurance and using APL has a lot to do with it
> I think).  First, single letter variable names are hard to search on.

Cross-reference is your friend.

> So are variable names that form parts of common words.  Second, once
> the habit develops, it's easy to run out of variable names and end up
> using "l" (lower case L), which is identical to "1" (one) in many
> fonts which can lead to very difficult to identify bugs.  Third,
> actuarial science has its share of accepted one letter values--"Q" for
> example is mortality.
> 
> Then there's the guy who used Z for whatever was returned by a
> function, _any_ function..  But somehow Z managed to escape and become
> globalized, so finding out what changed Z becomes a major undertaking.
> 
>> I allow global names to be longer, but look
>> for ways to abbreviate them too.
>> 
>> /Jorgen
> 



-- 
Pete