-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find longest functions and split them #5917
Comments
I think 85 is a good number. Are we going to also count comments? Some overload-related functions contain several detailed comments, which makes them visually long, but conceptually simple. |
This wouldn't be a hard rule. If very long comments make the function easier to understand, they may be fine. But I think that comments and docstrings should generally be included in the line count, since they can result in the function being too long to be viewed without scrolling. |
OK, I agree. |
FWIW, here are functions with ~80 lines or more that I could find (the numbers are approximate):
|
Is this issue still relevant? Might pick this one up. |
The mypy codebase has quite a few long functions, which is a problem since long functions are often hard to understand and modify. Once you can't see the whole function without scrolling, it's probably too long.
I think that we should refactor at least some of the longest functions into smaller ones. One way would be to systematically find all the longest functions and split them if they are hard to understand.
Not sure what is a good threshold. My editor can show 97 rows at a time on the display I typically use. I think that 97 rows is already too much most of the time. 75 rows per function might be a reasonable threshold above which we should consider taking action in code reviews. Thoughts?
The text was updated successfully, but these errors were encountered: