Regarding coding style
Lie
Lie.1296 at gmail.com
Tue Mar 11 12:31:09 EDT 2008
On Mar 10, 4:16 am, castiro... at gmail.com wrote:
> On Mar 9, 4:25 am, Lie <Lie.1... at gmail.com> wrote:
>
> > On Mar 9, 3:27 am, castiro... at gmail.com wrote:
>
> > > To Lie:
>
> > > > Personally I preferred a code that has chosen good names but have
> > > > little or no comments compared to codes that makes bad names and have
>
> > > Personally I don't. Show me a good one. Until you do, it's not that
> > > I won't like it, it's that I can't. You know, in linguistics, there's
>
> > But I much prefer it that the code has good names AND concise
> > comments, not too short and not too long that it becomes obscure.
>
> What do you mean? If 'obscure' is the right word, then it's
> subjective (from metrics import obscurity?), which means that 10% of
> the people disagree with you, or 90% do. The end-all be-all, there is
> no such thing. I don't think it's obscure; I do. Is it?
No, there is a point where everyone would say obscure. Such as a
simple two integer addition function that have thirty pages of
documentation and that have names like:
def dosomereallyfunkythings(argumentoneissomethingadded,
argumentbisaddinga):
""" blah blah blah blah
...
30 or so pages later...
...
Ok, that is the end of it, it's a complex function actually
"""
return argumentoneissomethingadded + argumentbisaddinga
(remember you don't have access to source code, so you have to
decipher the documentation for what the function is about)
I prefer to see something like this:
def add(a, b):
return a + b
Even without documentation I'd know immediately what it does from the
name (add)
More information about the Python-list
mailing list