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.