On Sat, Apr 25, 2020 at 11:57 AM Sven Schreiber <svetosch(a)gmx.net> wrote:
Am 25.04.2020 um 16:04 schrieb Artur Tarassow:
>
> 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 ...).
Consistency is good, and maybe trumps other considerations. But I
think function packages are/should be allowed latitude relative to
built-in functions. There are no underscores in names of built-ins (I
think) but they seem fine to me for readability in function packages.
I guess one could make the same argument for Camel Case. My main
objection would be to names that are (a) too long (though they can be
longer than the names of built-ins) or (b) hard to read because they
use run-in wording without either underscores or Camel-Casing to
clarify.
Allin