pylint scores

[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?

On Sat, Jul 31, 2010 at 2:48 AM, Dan Stromberg <drsalists at gmail.com> wrote:
>
> 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.
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>



-- 
Matteo Landi
http://www.matteolandi.net/