On Sun, Aug 1, 2010 at 12:27 PM, News123 <news1...@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 <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 > -- Matteo Landi http://www.matteolandi.net/ -- http://mail.python.org/mailman/listinfo/python-list