🚀 go-pugleaf

On Tue, 2018-02-27, J  Clarke 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:
...
>>>>> 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.

But you don't usually search for names which have a scope limited to
(say) 5--10 lines.

   (Note the irony, which is typical for coding style discussions: I
   had to defend using long, descriptive variable names, and now I'm
   defending using one-letter ones.  Consistency is overrated.)

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

Hm, I've never seen that problem arise.  It would indeed be a problem,
and a symptom of an underlying problem. Generally, I limit the number
of variables in scope at any given time, because code is harder to get
wrong when there are few moving parts.

> Third, actuarial science has its share of accepted one letter
> values--"Q" for example is mortality.

Ok. Well, I didn't mean to suggest my set of names are always
applicable everywhere.

> 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

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