3 ms·

It's a violation of someone's coding standard, if it's not a violation of yours, then add it to your exclusion list. The point of the init warning is that

by frobozz 10y ago

It's a violation of someone's coding standard, if it's not a violation of yours, then add it to your exclusion list. The point of the __init__ warning is that a class without a constructor might not really be a class at all. Number and size of methods are both code smells that indicate that you might be creating a God Objects or God functions. If there's a good reason for an enormous function, then violations can be ignored on a case, project or user basis. I'd prefer a tool that can warn about that sort of thing, to one that can't. Most of the limits are configurable, and set to reasonably generous defaults. Methods per class is 20 and statements per method is 50.

raverbashing 10y ago
> is that a class without a constructor might not really be a class at all. Yes, but there are several cases where this doesn't matter. Exceptions for example. > Number and size of methods are both code smells Yes, but Pylint's default values comes from where? It's pretty easy to trigger them without being a God object 20 methods is fine, 50 lines is what fits in my terminal, and a lot of functions don't fit that (especially with blank lines, splitting lines bigger than 80 chars, etc
- deleted 10y ago
  [deleted]
- frobozz 10y ago
  > Exceptions for example. Exceptions are not an example. They should inherit from BaseException (PEP-352). BaseException has __init__, therefore any Exception has __init__ by inheritance. > 50 lines is what fits in my terminal, 50 statements, not 50 lines. Blank lines aren't statements, splitting a long line doesn't turn it into two statements. It's pretty rare to have a 50 statement method that doesn't violate Curly's Law. Personally, I'd make it much smaller. Depending on how much commentary and whitespace you put in, you could have 150 or more lines in a 50 statement function. > Yes, but Pylint's default values comes from where? It doesn't matter, pylint isn't an academic paper that requires every assertion to be backed up by experimental data and citations from peer-reviewed journals. It's a handy and easily configurable tool. I would guess that the numbers came from a couple of pylint developers having a conversation like "50 statements is pretty big for a function isn't it? Yes, let's make that the default limit." Were it hard-coded as a magic number deep in the pylint code, then perhaps they might need a bit more experimental validation behind those numbers.
jerf 10y ago
This seems like one of those articles where nobody seems to have read past the first couple of paragraphs. It doesn't matter how wonderful the warning about things missing __init__ are if it's buried in a pile of other noise. The noise is the problem, not the specific warnings. And the author has already provided a constructive solution to the problem other than "not linting", which is to start with a whitelist and slowly crank the linter up, providing instant value and a path to move forward to obtain incrementally more value over time, instead of trying to crank the linter down, which means a lot of work before you're provided with any value, followed even then by, in the real world, probably staring at the list of issues, getting overwhelmed, and deciding the code seems to be working fine the way it is so why bother? (Remember, we are not superhumans. None of us respond to a list of 20,000 style issues by dropping everything and fixing them all. This is not even wrong; we can not operate like that, so there's no point in pretending that we either do or should.)
- falcolas 10y ago
  If you have 20,000 style issues, spending an hour to make a .pylintrc that matches your style spec will take care of all of those. And once done, it can be shared with all of your coders. It's not really that onerous. Pylint is also best used in tandem with an editor or IDE, so you can get live feedback.
- gbog 10y ago
  First thing I do with a legacy code base is to commit it to git, then pass it through pep8 and pylint to get a sense of its level of dirtyness, then run autopep8 to fix all that can be autofixed. Then commit the autofix. Then manually fix the remaining pep8 warnings after muting the ones that are too many. Then run pylint on it. I'll mute some of the most offended violations, and fix the others, so to have pyflakes and pylint run with zero warnings. Then hook the linters in ci, so the dirtyness do not come back through the window. In this process, I may exclude a folder or two if they are non vital and have a lot of dirty files. I think I have fixed code with nearly 10.000 violations this way, it takes 3 hours max if you use an efficient editor. Then the code is is some shape that you can start working on.
- frobozz 10y ago

It's a violation of someone's coding standard, if it's not a violation of yours, then add it to your exclusion list. The point of the __init__ warning is that

by frobozz 10y ago

raverbashing 10y ago

> is that a class without a constructor might not really be a class at all. Yes, but there are several cases where this doesn't matter. Exceptions for example. > Number and size of methods are both code smells Yes, but Pylint's default values comes from where? It's pretty easy to trigger them without being a God object 20 methods is fine, 50 lines is what fits in my terminal, and a lot of functions don't fit that (especially with blank lines, splitting lines bigger than 80 chars, etc

deleted 10y ago
[deleted]
frobozz 10y ago
> Exceptions for example. Exceptions are not an example. They should inherit from BaseException (PEP-352). BaseException has __init__, therefore any Exception has __init__ by inheritance. > 50 lines is what fits in my terminal, 50 statements, not 50 lines. Blank lines aren't statements, splitting a long line doesn't turn it into two statements. It's pretty rare to have a 50 statement method that doesn't violate Curly's Law. Personally, I'd make it much smaller. Depending on how much commentary and whitespace you put in, you could have 150 or more lines in a 50 statement function. > Yes, but Pylint's default values comes from where? It doesn't matter, pylint isn't an academic paper that requires every assertion to be backed up by experimental data and citations from peer-reviewed journals. It's a handy and easily configurable tool. I would guess that the numbers came from a couple of pylint developers having a conversation like "50 statements is pretty big for a function isn't it? Yes, let's make that the default limit." Were it hard-coded as a magic number deep in the pylint code, then perhaps they might need a bit more experimental validation behind those numbers.

jerf 10y ago

This seems like one of those articles where nobody seems to have read past the first couple of paragraphs. It doesn't matter how wonderful the warning about things missing __init__ are if it's buried in a pile of other noise. The noise is the problem, not the specific warnings. And the author has already provided a constructive solution to the problem other than "not linting", which is to start with a whitelist and slowly crank the linter up, providing instant value and a path to move forward to obtain incrementally more value over time, instead of trying to crank the linter down, which means a lot of work before you're provided with any value, followed even then by, in the real world, probably staring at the list of issues, getting overwhelmed, and deciding the code seems to be working fine the way it is so why bother? (Remember, we are not superhumans. None of us respond to a list of 20,000 style issues by dropping everything and fixing them all. This is not even wrong; we can not operate like that, so there's no point in pretending that we either do or should.)

falcolas 10y ago
If you have 20,000 style issues, spending an hour to make a .pylintrc that matches your style spec will take care of all of those. And once done, it can be shared with all of your coders. It's not really that onerous. Pylint is also best used in tandem with an editor or IDE, so you can get live feedback.
gbog 10y ago
First thing I do with a legacy code base is to commit it to git, then pass it through pep8 and pylint to get a sense of its level of dirtyness, then run autopep8 to fix all that can be autofixed. Then commit the autofix. Then manually fix the remaining pep8 warnings after muting the ones that are too many. Then run pylint on it. I'll mute some of the most offended violations, and fix the others, so to have pyflakes and pylint run with zero warnings. Then hook the linters in ci, so the dirtyness do not come back through the window. In this process, I may exclude a folder or two if they are non vital and have a lot of dirty files. I think I have fixed code with nearly 10.000 violations this way, it takes 3 hours max if you use an efficient editor. Then the code is is some shape that you can start working on.
frobozz 10y ago