Most Java mistakes I see in code reviews come from the same 20 misunderstandings. After reviewing thousands of pull requests, these patterns keep showing up, especially from developers in their first 2 years. Here is what trips people up the most: → Using == instead of .equals() for String comparison → Mutating Date objects when LocalDate exists → Throwing checked exceptions for programming errors → Using raw types instead of generics → Concatenating Strings in loops instead of StringBuilder → Writing nested null checks instead of using Optional → Defaulting to arrays when ArrayList gives you flexibility → Wrapping everything in synchronized when ConcurrentHashMap exists → Catching Exception instead of the specific type you expect → Making utility methods static when they should be instance methods → Using new String("hello") instead of string literals → Using Integer when int would suffice → Repeating type args instead of using the diamond operator → Manual close() in finally instead of try-with-resources → Using static final int constants instead of enums → Writing verbose for-if-add loops instead of streams → Using Arrays.asList when List.of gives true immutability → Spelling out full types when var keeps code clean → Writing boilerplate classes when records do the job → Concatenating strings with \n instead of using text blocks None of these are hard to fix once you see the pattern. The real problem is that nobody points them out early enough. Save this for your next code review. #Java #SoftwareDevelopment #Programming #CleanCode #CodingTips
Awesome check sheet! I completely agree with almost everything. However, I'm curious about your point on static utility methods. Since true utility classes are usually stateless, isn't making them static the standard approach? Would love to hear your thoughts on when they should be instance methods instead.
And they encapsutale collections like this: public class Pojo { pivate List<String> strings = new ArrayList<(); public List<String> getStrings() { return strings; } public void setStrings (List<String> strings) { this.strings = strings; } } instead of: public class Pojo { pivate List<String> strings = new LinkedList<>(); public List<String> getStrings() { return Collections.inmutableList(strings); } public void setStrings (List<String> strings) { this.strings.clear(); this.strings.addAll(strings); } }
Small improvements in code quality compound quickly. When teams focus on fundamentals, they reduce hidden bugs and improve long-term maintainability.
The best code review is the one that stops the same mistake from coming back next week 🫠
With the use of AI this mistakes are becoming more common. It's always good to use SonarQube and PMD to get this "typos" even before the code review.
Why exactly the "new ArrayList<Strring>(); " is a bad code? is that something we assign that arraylist to a String type list and that makesure the created array list is also String type? 🤔 or is there anything else as the reason to be this is bad?
really useful information, realized what i was doing wrong on some scenarios. thank you nelson!
What's the difference between those string comparison one using .equals or == is it performance related or could cause result in unexpected output
Thanks for sharing !I'll add "try-with-resources" to the list instead of "try-catch-finally" to avoid memory leaks.
Lists being better than arrays (sequential list) aren't always true. If performance is critical and the amount and the type of elements is known, array is better