🚀 go-pugleaf

J. Clarke <jclarke...@gmail.com> wrote:
> 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
>>> 
> 

Ut should be possible to generate one. Most other languages have it
built-in.

-- 
Pete