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,_
Hope, that this gave you some ideas
>
> On Sat, Jul 31, 2010 at 2:48 AM, Dan Stromberg <drsali...@gmail.com> wrote:
>>
>> On Fri, Jul 30, 2010 at 12:18 PM, News123 <news1...@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
