We've previously covered at What to Look for in Java 8 Code, now Java is moving faster than ever it's time to do an update and cover what to look for in Java 9 code. While Java 9 has even now been replaced with Java 10, and Java 11 in coming in September, these Java 9 features are, of course, available in Java 10 and 11. If your application is using any version later than Java 8 you may benefit from these tips. (more…)

In earlier blog posts we've talked about general things to look for during a code review. Recently I've been working a lot with Java 8, and I'm starting to have some opinions on what modern Java code should look like.  I've written about some of my Top Tips from an IntelliJ IDEA point of view, but I'd like to share these and more in the form of feedback you could give during a review of Java 8 code. Just a quick note on the screenshots in this post: I'm (mostly) using the single page diff that's the default view in an Upsource review (with white-space changes turned off). Code with a red ba

We’ve had two themes running through the articles on what to look for in a code review: Lots of what we’re tempted to look for can (and should) be automated Humans are good at checking things computers can not. In this final post in the series, we’re going to look at the grey area in between - we’re going to look at how the features in Upsource can make your job as a human code reviewer easier. As a developer, code reviews can sometimes be a frustrating process - you’re used to all the power of your IDE, yet when you open up a set of changes in your code review tool you can't lever

This is part 6 of 6 posts on what to look for in a code review. See previous posts from the series. How much work you do building a secure, robust system is like anything else on your project - it depends upon the project itself, where it’s running, who’s using it, what data it has access to, etc. Often, if our team doesn't have access to security experts, we go too far in one direction or the other: either we don’t pay enough attention to security issues; or we go through some compliance checklist and try to address everything in some 20 page document filled with potential issues. As us

This is part 5 of 6 posts on what to look for in a code review. See other posts from the series. In today's post we'll look more closely at the design of the code itself, specifically checking to see if it follows good practice Object Oriented Design.  As with all the other areas we've covered, not all teams will prioritise this as the highest value area to check, but if you are trying to follow SOLID Principles, or trying to move your code in that direction, here are some pointers that might help. What is SOLID? The SOLID Principles are five core principles of Object Oriented design

This is part 4 of 6 posts on what to look for in a code review. See previous posts from the series. Data structures are a fundamental part of programming - so much so it's actually one of the areas that's consistently taught in Computer Science courses. And yet it's surprisingly easy to misuse them or select the wrong one. In this post, we're going to guide you, the code reviewer, on what to look out for - we're going to look at examples of code and talk about "smells" that might indicate the wrong data structure was chosen or that it's being used in an incorrect fashion. Lists Probably t

This is part 3 of 6 posts on what to look for in a code review. See other posts from the series. In part three of our series on code reviews, we’re going to cover what you can look for in terms of the performance of the code under review. As with all architecture/design areas, the non-functional requirements for the performance of a system should have been set up-front. Whether you're working on a low-latency trading system which has to respond in nano-seconds, you're creating an online shopping site which needs to be responsive to the user, or you're writing a phone app to manage a "To

This is part 2 of 6 posts on what to look for in a code review. See other posts from the series. In the last post we talked about a wide variety of things you could look for in a code review. Now we’ll focus on one area: what to look for in the test code. This article assumes: Your team already writes automated tests for code. The tests are regularly run in a Continuous Integration (CI) environment. The code under review has been through an automated compile/test process and passed. In this post we’ll cover some of the things a reviewer could be thinking about when looking at

This is part 1 of 6 posts on what to look for in a code review. See other posts from the series. Let’s talk about code reviews. If you take only a few seconds to search for information about code reviews, you’ll see a lot of articles about why code reviews are a Good Thing (for example, this post by Jeff Atwood). You also see a lot of documentation on how to use Code Review tools like our very own Upsource. What you don’t see so much of, is a guide to things to look for when you’re reviewing someone else’s code. Probably the reason there’s no definitive article on what to be lookin