🚀 go-pugleaf

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