pylint scores

[wheres pythonmonks]

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)

Somewhat related: Is the backslash the only way to extend arguments
to statements over multiple lines? (e.g.)
.... 3)
6 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

 

[Peter Otten]

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)

No. About 5 is typically OK for undocumented code.
I've heard.

Ratings do not always make sense:

$ for f in /usr/lib/python2.6/{glob,csv,doctest,collections}.py; do echo $f;
pylint 2>/dev/null $f | grep "Your code has"; done
/usr/lib/python2.6/glob.py
Your code has been rated at 8.54/10
/usr/lib/python2.6/csv.py
Your code has been rated at 6.45/10
/usr/lib/python2.6/doctest.py
Your code has been rated at 7.77/10
/usr/lib/python2.6/collections.py
Your code has been rated at -4.71/10
$

For mainstream code you can easily reach 10 by adding bogus docstrings and
pointless long variable names, i. e. you can get higher scores for lower
code quality.

Peter

PS: My favourite wtf message is "too few public methods"

 

[News123]

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.

... 3)
6File "<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

 

[Matteo Landi]

What are the messages one should really care about while evaluating
its code using pylint? It's easy to get 5 scored with a "lot of public
methods" or bad named variables such as 'x' or 'y' .. Have you got any
config file to share?

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.

 

[News123]

Hi,

What are the messages one should really care about while evaluating
its code using pylint? It's easy to get 5 scored with a "lot of public
methods" or bad named variables such as 'x' or 'y' .. Have you got any
config file to share?

The most important ones are of course the errors.
Some of them might be false, but in our team we agreed, that no file is
allowed to report pylint errors.
This means
- just fixing errors (in most cases)
- rewriting code (in a few cases)
- masking errors with pylint directives in the source (some other few
errrors)




If you only want to see the errros, then just run
pylint -E filename.py

Note: This is a rather new but very useful switch.. It doesn't exist
on Ubuntu 10.4's release pylint 0.19.0, but exists on pylint 0.21.1



Apart from that. You should discuss within your team, which
errors you'd like to have ignored and adapt the pylintrc. This
is a rather personal decision.
For one project we disiabled for example following warnings:
## C0322 = "Operator not preceded by a space"
## C0323 = "Operator not followed by a space"
## C0324 = "Comma not followed by a space"
As we did not have time to rewrite all of the existing code, that
violated these rules.
We prefered to 'hide' these warnings in order to sett the more important
ones.

On another new project however we did NOT comment therese rules
and decided, that all new code should follow these rules


We disabled some special global variables, which we'd like to have in
lower case

const-rgx ==((specialvar)|(v_[a-z_][a-z0-9_]*)|([A-Z_][A-Z0-9_]*)|(__.*__))$


you could also modify variables like
# Maximum number of attributes for a class (see R0902).
max-attributes=7

# Minimum number of public methods for a class (see R0903).
min-public-methods=2

# Maximum number of public methods for a class (see R0904).
max-public-methods=20


For some graphics module functions for example we wanted to
be allowed to use variable names like x,y as they are
completely meaningful names for pixel coordinates.


so change the entry good-names
good-names=x,y,ex,Run,_



Hope, that this gave you some ideas

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.

 

[Matteo Landi]

Hi,

What are the messages one should really care about while evaluating
its code using pylint? It's easy to get 5 scored with a "lot of public
methods" or bad named variables such as 'x' or 'y' .. Have you got any
config file to share?

The most important ones are of course the errors.
Some of them might be false, but in our team we agreed, that no file is
allowed to report pylint errors.
This means
- just fixing errors (in most cases)
- rewriting code (in a few cases)
- masking errors with pylint directives in the source (some other few
errrors)




If you only want to see the errros, then just run
pylint -E filename.py

Note: This is a rather new but very useful switch.. It doesn't exist
   on Ubuntu 10.4's release pylint 0.19.0, but exists on pylint 0.21.1



Apart from that. You should discuss within your team, which
errors you'd like to have ignored and adapt the pylintrc. This
is a rather personal decision.
For one project we disiabled for example following warnings:
## C0322 = "Operator not preceded by a space"
## C0323 = "Operator not followed by a space"
## C0324 = "Comma not followed by a space"
As we did not have time to rewrite all of the existing code, that
violated these rules.
We prefered to 'hide' these warnings in order to sett the more important
ones.

On another new project however we did NOT comment therese rules
and decided, that all new code should follow these rules


We disabled some special global variables, which we'd like to have in
lower case

const-rgx ==((specialvar)|(v_[a-z_][a-z0-9_]*)|([A-Z_][A-Z0-9_]*)|(__..*__))$


you could also modify variables like
# Maximum number of attributes for a class (see R0902).
max-attributes=7

# Minimum number of public methods for a class (see R0903).
min-public-methods=2

# Maximum number of public methods for a class (see R0904).
max-public-methods=20


For some graphics module functions for example we wanted to
be allowed to use variable names like x,y as they are
completely meaningful names for pixel coordinates.


so change the entry good-names
good-names=x,y,ex,Run,_

Thank you so much, these are very precious settings.

Hope, that this gave you some ideas

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.