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