Steve Litt <sl...@troubleshooters.com> writes:
> Apollia <apollia...@gmail.com> wrote:
>>> <rainerweiku...@virginmedia.com> 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.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
