pylint scores

[Dan Stromberg]

On Fri, Jul 30, 2010 at 12:18 PM, News123 <news1234 at free.fr> wrote:

> On 07/30/2010 03:12 PM, wheres pythonmonks wrote:
> > I am starting to use pylint to look at my code and I see that it gives a
> rating.
> > What values do experienced python programmers get on code not
> > targeting the benchmark?
> >
> > I wrote some code, tried to keep it under 80 characters per line,
> > reasonable variable names, and I got:
> >
> > 0.12 / 10.
> >
> > Is this a good score for one not targeting the benchmark?  (pylint
> > running in default mode)
> >
> It's not a goodf core, but arrives easily if you never ran pylint before.
> With very little effort you should be able to be above 5
> with a little more effort above 7
>
>
> > Somewhat related:  Is the backslash the only way to extend arguments
> > to statements over multiple lines?  (e.g.)
>
> if you have an opening parenthesis, or bracked, then you don't need a
> backslash
>
> so instead of
> if longlonglonglonglonglonglonglongvar == \
>        otherlonglonglonglongvar:
>
> you could also write:
>
> if (longlonglonglonglonglonglonglongvar ==
>        otherlonglonglonglongvar):
>
>
> same works of course with asserts.
>
> >
> >>>> def f(x,y,z): return(x+y+z);
> > ...
> >>>> f(1,2,
> > ... 3)
> > 6
> >>>> assert f(1,2,3)>0,
> >   File "<stdin>", line 1
> >     assert f(1,2,3)>0,
> >                      ^
> > SyntaxError: invalid syntax
> >>>>
> >
> > In the above, I could split the arguments to f (I guess b/c of the
> > parens) but not for assert.  I could use a backslash, but I find this
> > ugly -- it that my only (best?) option?
> >
> > [I really like to assert my code to correctness and I like using the
> > second argument to assert, but this resulted in a lot of long lines
> > that I was unable to break except with an ugly backslash.]
> >
> > W
>
> IMO, the important thing about pylint's scoring is that it's but one way of
many of producing good Python code.  However, it's also one of the easier
ways of producing good python code.

I personally like to get my scores up near 10, by annotating in comments
about the few things that pylint flags that I can't just code around.  This
requires jumping through some slightly silly hoops (EG the previously
mentioned "too few public methods", which my various container classes
always trip over), but going through this process is worthwhile for
highlighting the hoops pylint can detect that -aren't- so silly.

The one thing I like to leave unfixed is FIXME's - otherwise my preference
would be to go for a score of 10 for production code.

I also like to create a ./this-pylint script for my various projects, that
have global overrides - things like identifier rules, line length, and...  I
don't get blanks instead of tabs.  Blanks are fine if you don't understand
tabs (or think someone in the future who doesn't understand tabs will need
to work on your code), but tabs allow everyone to see code indented the way
-they- want to see it, not just the way the original author wanted to see
it.

This script (./this-pylint) will also save output from the test in a text
file, for make (or other dependency handling program) to use to avoid
re-pylint'ing unmodified code.  It'll give an error typically, if pytlint
detects any errors other than FIXME's (excluding ones, as I mentioned
before, that have a comment disabling the warning, of course).

I'm more than a little sad that pylint doesn't seem to be moving to python 3
in any big hurry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100730/e4b21821/attachment-0001.html>