🚀 go-pugleaf

On Tue, 27 Feb 2018 15:44:57 -0700, Peter Flass
<peter...@yahoo.com> wrote:

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

Please provide a "cross reference" for APL.

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