Am 25.04.20 um 17:56 schrieb Sven Schreiber:
Am 25.04.2020 um 16:04 schrieb Artur Tarassow:
> Am 25.04.20 um 15:42 schrieb Riccardo (Jack) Lucchetti:
>> On Sat, 25 Apr 2020, Sven Schreiber wrote:
>>> Hehe, I think I "incepted" you, see three replies earlier. I
don't
>>> like
>>> the underscore too much though (but it's not a full veto). syseqdraw?
>>> multieqdraw?
>>
>> MultiEqDraw()?
That would be CamelCase - see below.
> I am more or lessĀ indifferent wrt to the function name as such. It
> should be meaningful and intuitive.
>
> However, we _should_ to be consistent as possible regarding naming
> conventions. Unfortunately we've missed to define some conventions for
> the "extra" package which is authored by different people at the
> beginning. Currently we have almost all possible naming styles in
> "extra".
Yeah, almost - we don't have camel case in extra and I think Allin
stated that he doesn't like that. And of course Jack's gap_filler is the
only underscore around, and it would be easy to introduce an official
alias 'gapfiller'.
I agree some convention might be good, to an extent. But we already have
a loose de-facto standard that you can see when looking at the list of
gretl functions: No CamelCase, no underscores, nothing too long,
uppercase only when it's an acronym (although it's actually inconsistent
then to have kpsscrit, bkfilt, bkw, ghk ...).
(Note that personally I like CamelCase, but that's not the point.)
I have become a fan of meaningful function names -- length doesn't
bother me. I want to read the function's name and have an idea what it
is good for instead of studying its description or code in detail.
Especially once a project gets bigger, bad variable and function names
make it difficult to manage and coordinate efforts. But ok, this is
another issue to be discussed ;-)
Artur