Replies: 1 comment 2 replies
-
This could potentially be useful... But to be honest cognitive complexity also quantifies nesting. I think it achieves what you want while being more general than just counting nesting level. See also #3295 I think it might need some tests for anonymous classes, like the example you linked. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I see that PMD has some specialized rules to avoid deep nesting for if statements.
CheckStyle has a triplet of rules to limit nesting fors, ifs and try.
However, looking around, I'm not finding a general nesting limit rule, e.g. something that would complain if there is, for example, an if nested in a for nested in a lambda nested in a switch nested in a couple of levels of ifs (you get the idea I believe).
If a bit of code has a mix of structures nested, and the nesting becomes too deep, the ability to undrestand the code goes down quickly. In presence of automatic formatting that limits the number of columns, readability quickly suffers too.
E.g., here is an example that just ends up looking bad, and in which code intentions and structure begin to get lost (as automatically formatted by Google Java formatter, with AOSP code style):
https://github.com/geoserver/geoserver/blob/9e40cbbccb9626b8d08516c8eacaf5a8f168189b/src/web/core/src/main/java/org/geoserver/web/GeoServerBasePage.java#L271
What about a rule that flags these cases?
Beta Was this translation helpful? Give feedback.
All reactions