mixed solution: unicase (unique allowed case) (was: Re:
Tim Rowe
digitig at cix.co.uk
Mon Jun 5 18:04:00 EDT 2000
In article <5Ys_4.5311$Hz.39657 at news-server.bigpond.net.au>,
neilh at scintilla.org (Neil Hodgson) wrote:
> So it is a required parameter? In the original problem statement it
> was
> an optional parameter, which is why the name is more prominent. I agree
> that
> the primary subject of a call may sensibly follow a different naming
> scheme
> than a bunch of optional arguments which generally indicate
> 'flavourings' of
> a call.
In my particular case it is required, but if the method had a default
Canvas, making canvas an optional parameter, I'd use the same convention.
> Mmm. Fixing up Python's lack of strictly typed parameters ;)
AIUI, Python /does/ have strictly typed parameters. It strictly checks
that all parameters are objects :-)
More seriously, if you start making changes like that you move Python in
the direction of being C++ (with STL). If I want that, I /use/ C++!
> I'm thinking about moving the opposite way (I sometimes currently use
> lower case class names for class instances) and starting to write
> aCanvas
> rather than canvas as it doesn't seem much additional verbiage to
> remove an
> opportunity for confusion.
It's not the additional verbiage; it's the fact that /every/ parameter has
to have the prefix, or you have to remember which parameters have, which
haven't. You then have a naming scheme that's inconsistent with the
standard libraries, so you have to remember where a function comes from...
I found that the "a_" convention caused /more/ confusion than the
upper/lower case convention, and that the "opportunity for confusion" in
the latter was entirely theoretical. Of course, you may work in a
different way and find the opposite, but there seemed to be an opinion in
this thread that I should be prevented from working in a way /I/ find
reliable and effective, to no benefit that I can see. By all means have
editors or static checkers with the /option/ of looking for this, but no
enforcement in the language, please!
More information about the Python-list
mailing list