4 ms·

I'm also not a fan of pylint - and I just ran it against a small project, 812 LOC of Python. The code was developed with help of the 'pep8' tool which only fin

by wink 10y ago

I'm also not a fan of pylint - and I just ran it against a small project, 812 LOC of Python. The code was developed with help of the 'pep8' tool which only finds 12 offending lines we declared ok (all too long, but it's SQL where formatting for readability is more important than 80 chars..) and wlthough pylint gives it a 7.26/10 there's a TON of errors. So yes, I could now spend a while blacklisting some rules, fixing some stuff, but the defaults are just so bad I won't bother, as usual. Because I think the shape of this code is pretty good.

itamarst 10y ago
This is why I suggested whitelisting, because it's much faster. So you get some checks going immediately.
- falcolas 10y ago
  The problem with whitelisting is that you never un-whitelist some things, depriving yourself of potentially useful feedback. Better to run with -E first, address those, then add in warnings, and blacklist the points which are actually not useful.
gbog 10y ago
I beg to differ, to me python (and js) are tolerable languages only when they are controlled with linters and automated tests. And pylint is still the best linter for big python projects. It is fully configurable and each and every default rule is interesting per se. For example, a class with no `__init__`, no or too many attributes or methods, is a potential code smell and candidate for refactoring.
- emidln 10y ago
  Pylint complains about: foo = functools.partial(bar, 'baz') because it thinks foo is a global constant and thus should be upcased. It can DIAF.
  - tclancy 10y ago
    This is exactly why it has ignore flags. Remember Python's attitude is "explicit is better than implicit": if you know what you are doing, you just put a flag over it. pylint is trying to catch the cases where a person didn't know what they're doing. I'd rather have to add a flag than have it miss those.
  - gbog 10y ago
    Are you not in the module's global scope? If you are pylint is right and you wrong, you need to move this line inside a function or a class. There should be no code running at module level. Here you might argue that this is akin to a decorator, and that bar will not be called, so yes it is a corner case, but the main rule (only allow consts at module level) is still useful, and I'd say vital even.
    - emidln 10y ago
      This is not 'akin to a decorator', it's is partial function! Do you name your functions: def THIS_IS_IN_GLOBAL_SCOPE(): ... Of course you don't! Then why would you consider forcing someone to write this: def bar(spam, eggs): print spam, eggs def foo(eggs): return bar('baz', eggs) Which even manages to lose information, hence why functools.partial exists in the first place. This is bad because readers now see FOO and think it's a constant: FOO = functools.partial(bar, 'baz')
- sly010 10y ago
  I don't know any other linter for any other language that complains about too many methods (or too many lines in a method, or too long variable names, etc) in a class. I should know my domain better than pylint.
  - tclancy 10y ago
    It's not specific to a language. Those are all code complexity measures. When you see those flags you should at least consider refactoring (and if things are best the way they are you can put a pylint-ignore comment with an explanation right above it).
  - web007 10y ago
    Perl generates McCabe scores, and can arbitrarily limit on complexity. That's a better proxy than "number of lines", but tends to be equivalent.
  - frobozz 10y ago
    PMD: http://pmd.sourceforge.net/snapshot/pmd-java/rules/java/codesize.html#ExcessivePublicCount http://pmd.sourceforge.net/snapshot/pmd-java/rules/java/code... Scalastyle: http://www.scalastyle.org/rules-0.8.0.html#org_scalastyle_scalariform_NumberOfMethodsInTypeChecker http://www.scalastyle.org/rules-0.8.0.html#org_scalastyle_sc... JSHint: http://jshint.com/docs/options/#maxstatements http://jshint.com/docs/options/#maxstatements
web007 10y ago
> Because I think the shape of this code is pretty good. That's the wrong attitude. Nobody commits code they don't think is good, but unless you measure "good" objectively and thoroughly there can always be problems you don't notice. The entire point of the article is that there ARE bugs buried in all that noise, and that you can surface and prevent them from being Future Wink's problem by spending an hour today to fix the tooling. For 800 lines it should take you far less than an hour, and if there is a "TON" of complaints there are probably one or 2 real bugs. Multiply that by 10k LOC and you start to realize the scope of the problem. Take the pain, fix it today while you are just at 800, so when you're 1000 or 5000 it's 5000 lines of better code.

by wink 10y ago

itamarst 10y ago

This is why I suggested whitelisting, because it's much faster. So you get some checks going immediately.

falcolas 10y ago
The problem with whitelisting is that you never un-whitelist some things, depriving yourself of potentially useful feedback. Better to run with -E first, address those, then add in warnings, and blacklist the points which are actually not useful.

gbog 10y ago

I beg to differ, to me python (and js) are tolerable languages only when they are controlled with linters and automated tests. And pylint is still the best linter for big python projects. It is fully configurable and each and every default rule is interesting per se. For example, a class with no `__init__`, no or too many attributes or methods, is a potential code smell and candidate for refactoring.

emidln 10y ago
Pylint complains about: foo = functools.partial(bar, 'baz') because it thinks foo is a global constant and thus should be upcased. It can DIAF.
- tclancy 10y ago
  This is exactly why it has ignore flags. Remember Python's attitude is "explicit is better than implicit": if you know what you are doing, you just put a flag over it. pylint is trying to catch the cases where a person didn't know what they're doing. I'd rather have to add a flag than have it miss those.
- gbog 10y ago
  Are you not in the module's global scope? If you are pylint is right and you wrong, you need to move this line inside a function or a class. There should be no code running at module level. Here you might argue that this is akin to a decorator, and that bar will not be called, so yes it is a corner case, but the main rule (only allow consts at module level) is still useful, and I'd say vital even.
  - emidln 10y ago
    This is not 'akin to a decorator', it's is partial function! Do you name your functions: def THIS_IS_IN_GLOBAL_SCOPE(): ... Of course you don't! Then why would you consider forcing someone to write this: def bar(spam, eggs): print spam, eggs def foo(eggs): return bar('baz', eggs) Which even manages to lose information, hence why functools.partial exists in the first place. This is bad because readers now see FOO and think it's a constant: FOO = functools.partial(bar, 'baz')
sly010 10y ago
I don't know any other linter for any other language that complains about too many methods (or too many lines in a method, or too long variable names, etc) in a class. I should know my domain better than pylint.
- tclancy 10y ago
  It's not specific to a language. Those are all code complexity measures. When you see those flags you should at least consider refactoring (and if things are best the way they are you can put a pylint-ignore comment with an explanation right above it).
- web007 10y ago
  Perl generates McCabe scores, and can arbitrarily limit on complexity. That's a better proxy than "number of lines", but tends to be equivalent.
- frobozz 10y ago
  PMD: http://pmd.sourceforge.net/snapshot/pmd-java/rules/java/codesize.html#ExcessivePublicCount http://pmd.sourceforge.net/snapshot/pmd-java/rules/java/code... Scalastyle: http://www.scalastyle.org/rules-0.8.0.html#org_scalastyle_scalariform_NumberOfMethodsInTypeChecker http://www.scalastyle.org/rules-0.8.0.html#org_scalastyle_sc... JSHint: http://jshint.com/docs/options/#maxstatements http://jshint.com/docs/options/#maxstatements

web007 10y ago

> Because I think the shape of this code is pretty good. That's the wrong attitude. Nobody commits code they don't think is good, but unless you measure "good" objectively and thoroughly there can always be problems you don't notice. The entire point of the article is that there ARE bugs buried in all that noise, and that you can surface and prevent them from being Future Wink's problem by spending an hour today to fix the tooling. For 800 lines it should take you far less than an hour, and if there is a "TON" of complaints there are probably one or 2 real bugs. Multiply that by 10k LOC and you start to realize the scope of the problem. Take the pain, fix it today while you are just at 800, so when you're 1000 or 5000 it's 5000 lines of better code.