🚀 go-pugleaf

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 allow global names to be longer, but look
for ways to abbreviate them too.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .