Pylint warns if you have “more than X” for a lot things like local variables, number of arguments, number of member variables, etc.
For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines.
I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written.
A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically.
So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.
Yup. I would like to keep things on the screen if feasible, but it's really always cyclomatic complexity that matters. A linear flow of lines, I don't care about until I can't see it all at once but you're rarely writing a linear flow of lines.
I always felt that true "scripting" with a "scripting language" was two things:
1) Most of your functions were linear: low cyclomatic complexity.
2) Functions rarely called into other functions.
While "programming" moves away from both of those:
1) Higher cyclomatic complexity is allowed.
2) Functions frequently call into other functions.
For instance, I like bash only for scripting. The moment it starts to resemble programming, I tend to switch to Python. However, some people are fine doing a fair amount of "programming" in bash, people who know it really well.
For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines.
I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written.
A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically.
So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.