pylint scores

Fri Aug 6 08:49:04 EDT 2010

On Sun, Aug 1, 2010 at 12:27 PM, News123 <news1234 at free.fr> wrote:
> Hi,
>
>
> On 07/31/2010 11:04 AM, Matteo Landi wrote:
>> 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 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
>>>
>>>
>>
>>
>>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

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