Am 25.04.20 um 15:42 schrieb Riccardo (Jack) Lucchetti:
On Sat, 25 Apr 2020, Sven Schreiber wrote:
>> Actually, we could go for a name that emphasises the _purpose_ of the
>> function. How about multieq_draw(); then of course we need to explain
>> thoroughly what it does and how in the docs, but IMO the name is nice
>> and easy to remember.
>
> 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()?
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".
Actually I would plead for settings some conventions for new packages/
functions and put it into the "Function package guide". For
standardizing things, we need some decisions on:
- public functions
- private functions
- package names
- constant variables
- doc strings
The Python community has defined the well-known PEP8 conventions -- and
I think those are very helpful:
https://stackoverflow.com/a/50958547