3 ms·

> The real problem is the amount of output. That's a nonsense argument. The output is proportional to the number of violations. If you keep your project clea

by frobozz 10y ago

> The real problem is the amount of output. That's a nonsense argument. The output is proportional to the number of violations. If you keep your project clean, then you'll have about a report of about 100 lines showing the statistics, with a one-line message: "your code has been rated at 10/10" at the end. Of course, if you run it against a project that is full of violations, you'll get lots of violation messages. If you use a linter or style checker or whatever on a project that is full of violations, and it doesn't produce lots of output, then the tool is rubbish. The right thing to do is to use it from the start and either fix or explicitly ignore any violations as they come up. The approach described in this blog post is good for existing projects. However, the linked examples disable all warnings and explicitly enable those that the author has deemed important. It would be better to explicitly disable unimportant ones.

raverbashing 10y ago
But having classes without an __init__ method is not a violation. (Amongst several other warnings, like number of methods, size of methods, etc) Don't get me wrong, pylint is great, but at some point it seems those tools begin to get opinionated instead of helping
- 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.)

by frobozz 10y ago

raverbashing 10y ago

But having classes without an __init__ method is not a violation. (Amongst several other warnings, like number of methods, size of methods, etc) Don't get me wrong, pylint is great, but at some point it seems those tools begin to get opinionated instead of helping

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.)