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 <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 > > -- Matteo Landi http://www.matteolandi.net/ -- http://mail.python.org/mailman/listinfo/python-list
