https://www.veracode.com/blog/secure-development/avoiding-nested-try-catch-java
Extracting the nested part as a new method will always work for any arbitrarily nested Try-Catch-Finally block. So this is one trick that you can always use to improve the code.
return early
https://www.codeproject.com/Articles/626403/How-and-Why-to-Avoid-Excessive-Nesting
Replace Nested Conditional with Guard Clauses
https://refactoring.guru/replace-nested-conditional-with-guard-clauses
Isolate all guard clauses that lead to calling an exception or immediate return of a value from the method. Place these conditions at the beginning of the method.
After rearrangement is complete and all tests are successfully completed, see whether you can use Consolidate Conditional Expression for guard clauses that lead to the same exceptions or returned values.
https://testing.googleblog.com/2017/06/code-health-reduce-nesting-reduce.html
The refactoring technique shown above is known as guard clauses. A guard clause checks a criterion and fails fast if it is not met. It decouples the computational logic from the error logic. By removing the cognitive gap between error checking and handling, it frees up mental processing power. As a result, the refactored version is much easier to read and maintain.
Here are some rules of thumb for reducing nesting in your code:
- Keep conditional blocks short. It increases readability by keeping things local.
- Consider refactoring when your loops and branches are more than 2 levels deep.
- Think about moving nested logic into separate functions. For example, if you need to loop through a list of objects that each contain a list (such as a protocol buffer with repeated fields), you can define a function to process each object instead of using a double nested loop.
https://dzone.com/articles/code-smells-deeply-nested-code
public MappedField getMappedField(final String storedName) {
for (final MappedField mf : persistenceFields) {
for (final String n : mf.getLoadNames()) {
if (storedName.equals(n)) {
return mf;
}
}
}
return null;
}
This what the Law of Demeter warns us against, therefore suggests to me we consider a tell-don’t-ask approach. Wouldn’t it be prettier to ask
mappedField if one of its names matched the name we wanted? public Optional<MappedField> getMappedField(final String storedName) {
return persistenceFields.stream()
.filter(mf -> mf.hasName(storedName))
.findFirst();
}
Symptoms:
- Deeply nested code, usually loops and/or conditionals
- Chained method calls that are all getters (or other non-builder, non-DSL method chains).
Possible solutions:
- Consider tell, don’t ask. Where the code previously grabbed internal data and did checks against it, move those checks into the object containing the data and create a method with a useful name to help other objects answer their questions.
- Examine your encapsulation. Does the data really need to leak out into other classes? Should data and/or responsibilities be relocated so that operations on the data are moved closer to the data itself?
- Collection Encapsulation. Sometimes this pattern is a sign that you’re using a data structure as a domain object. Consider encapsulating this data structure (Collection, array, etc) inside a domain object of its own and adding helper methods to let other objects ask it questions rather than poke around its internals.
public Optional<MappedField> getMappedField(final String storedName) {
return persistenceFields.stream()
.filter(mf -> mf.hasName(storedName))
.findFirst();
}
Refactoring with Cognitive Complexity
https://resources.sei.cmu.edu/asset_files/Presentation/2017_017_001_497517.pdf
Control flow statements "if", "for", "while", "switch" and "try" should not be nested too deeply
https://rules.sonarsource.com/java/RSPEC-134
