Useful utility methods in order to have easy-to-read and easy-to-understand code
Helmut Siegel
?? Senior Java/Angular Engineer | Results-driven Developer | B2B | Freelancer | Consultant | Spring | REST | Jenkins | Docker | AWS
The compiler understands the code even if it is messy, unstructured, or does not follow any clean code principles. That is not the case with developers. For developers, it is very important the code be easy to read and easy to understand. To achieve good readability there is a lot of good practice and principles to follow.
In this article, I want to share with you some useful utility methods that will contribute a lot to having easy-to-read and easy-to-understand code.
The java.util.Objects class contains utility methods for operating on objects.
The java.util.Objects class contains further utility methods, I highly recommend checking them out here.
The org.apache.commons.lang3.ObjectUtils classcontains utility methods for operating on objects.
The org.apache.commons.lang3.ObjectUtils class contains further utility methods, I highly recommend checking them out here.
领英推荐
The org.apache.commons.lang3.BooleanUtils class contains utility methods regarding boolean operations.
The BooleanUtils class contains further utility methods, recommend checking them out here.
The org.apache.commons.lang3.StringUtils contains String related utility methods. This class contains much more methods than the previously mentioned ones.
The StringUtils class contains further utility methods, recommend checking them out here.
Conclusion:
In this article, I listed only a few of the existing utility methods that can help you achieve clean and readable code. Through the listed methods you could see how much easier is to understand the code because the utility method names are human-readable.
I highly recommend you invest in learning how to clean code, because that will be beneficial for you, for the team, and for the client.
Staff Software Engineer at Google * Good Person to Know * Autistic * Now on Substack @leemckeeman!
3 年There are dozens of ways to skin a cat, and often a team needs to decide what their preferred ways are. Guava has MoreObjects.firstNonNull, there is Optional chaining: return Optional.of(employee).map(Employee::getDepartment).orElse(null) //Can use orElseGet with a supplier if default is expensive to compute Sometimes ternary works, and may be more “at home” final Department department = employee.getDepartment(); return (department == null ? defaultDepartment : department); Depending on the team, current dependency set, Java version, etc. any might be the preferred way. Edit to add: Picking any one way, and having the team agree and be consistent is frankly more important than which way. Even a suboptimal way that’s the same throughout your code, and easy enough to find and refactor or write a code mod for is better than having it done differently everywhere. Some code may be allocation sensitive, so Optional may not be great. Some code bases may be dependency sensitive, so writing your own small set of utilities may be better than Guava or Apache. It’s important to make a decision and get it vetted by the team than letting everyone do their own thing, though.
Software Craftsman, Educator, Author
3 年My randomo opinion: I flip and flop on these. The if statement version is pretty clear if you bin the else and have if (not null){ return thing; } return default; I'd be more sold if it had a different name like Nulls.valueOrDefault( thing, default ); I'd like it as a non-static private as well. But I really like the fact you're paying this attention, because the battle for clean code starts with lines like these.