:: Re: [DNG] Readable code; making cod…
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng
Subject: Re: [DNG] Readable code; making code more easily writable; Emacs, multifiles-apmod; VUE; Code Bubbles; Lisp; Inform 7; HyperCard and HyperTalk - was Re: "Common knowledge?"-question
Steve Litt <slitt@???> writes:
> Apollia <apollia112@???> wrote:
>>> <rainerweikusat@???> wrote:


[...]

>>>> I often like to use long, descriptive names for functions and
>>>> variables, no matter what language I'm using, even Bash.


[...]

>>> using an identifier combined-list-of-files-in-all-source-folders
>>> doesn't really communicate more than 'all-files' or even just 'all'
>>> (if the files is evident from the context) would.
>>
>> Thanks for the feedback! Perhaps as I get more comfortable with
>> programming in general I'll stop relying so much on the crutch of
>> overly verbose names. I know I overdo it to some extent.
>
> One man's opinion: Names explaining exact action and purpose are a
> good thing.


That's almost a truism. But "explaining exact action and purpose" isn't
necessarily something better accomplished by using longer names. Eg,
assuming I define a structure supposed to be part of a linked list, I
usually start that as

struct something {
    struct something *p;


if it doesn't contain anything else which naturally suggests itself for
the name 'the pointer'. p is a good name for a pointer and the context
is supposed to supply the information re: what 'the pointer'
specifically refers to. In the example above, it would obviously be 'the
link pointer'.

One could argue that such a convention should be documented in some kind
of 'the style explained' guide but apart from that, there's nothing
wrong with it.