10 Rules for writing code for junior Java developers
Rule 1: Functions shouldn’t run beyond your screen
This of course comes from the Linux coding guidelines. But I fear that most of our junior developers who are born and bread in Java have not really been exposed to these standards. Nowadays with high-resolution monitors and multiple displays its very easy for you to code functions that have complex behavior. This makes the code extremely unreadable and difficult to review or understand for someone new joining your team.
Rule 2: Validate input parameters to your functions
This is again an alarming trait that can be seen in some code, where developers just rely on a NullPointerException being thrown rather than validate input parameters. As if to promote bad code (too harsh?) Jdk 14 onwards you also have the XX:+ShowCodeDetailsInExceptionMessages option that will tell you exactly what variable caused the NPE. This should ONLY be used in the Development environment as it is a security risk as well as performance overhead.
Rule 3: Be aware of what happens with resources
It's sometimes very easy for Java programmers to fall into the trap thinking that because java has automatic garbage collection it is non of their concern. This leads to many memory leaks especially when it comes to holding on to resources such as sockets, files, database connections, etc. Always be aware of what is taken care of by the JVM and which resources need to be managed by yourselves
Rule 4: Time complexity matters
Although many of the programmers learn how to calculate time complexity as part of their degree they forget that something like that even existed when they start coding. Often Java programmers rely on the JDK routines to provide the most optimal algorithm for things like sorting.
Often more time is spent profiling and trying to figure out why a program has performance issues than is necessary. These can be easily rectified at the time of writing code if you understood the time complexity of each of the JDK functions and were aware of what those would do to your code.
Rule 5: Test-Driven Development (TDD)
Although this is preached like a mantra it still doesn’t seem to have become a religion for all new programmers. Often the excuse is that the project deadlines meant cutting down on writing unit tests. Strongly resist the temptation to do this as it is an evil that will consume you and keep you in programmers hell eternally.
Projects that do not practice TDD need multiple times QA engineers to find the issues in code. Another excuse for not doing TDD is when juniors developers are assigned to do an enhancement on legacy code that doesn’t have any test cases. This is often because we underestimate the power of Mocking frameworks.
Rule 6: Memory Matters
Memory used to be a scarce resource. A different generation might remember the time when you had to fit your code into 32KB of RAM. Nowadays we often see people look disgruntled when they have 32GB of Memory on their PCs.
Mind you, the Microsoft Operating system gulping down a lot of that memory hasn’t helped, nor has the fact that even doing a simple “Hello World” in Java was painfully memory-intensive until the Modular JDK Project.
However, adopting these changes in the Java platform into legacy code is still lagging. Try to minimize the memory footprint of your application even if you a not under duress to do so.
Rule 7: Memory Allocation
When are objects created and how many are created will also play a huge role in your application performance. Often someone might be cloning classes unnecessarily. There was a reason that everything is passed by reference in Java. However, if you blindly write “clone” methods and copy vast amounts of memory you lose this advantage.
You might not even notice there is an issue in object allocation because you have big enough Young Generation (in the old CMS terms) and the Garbage collector is efficiently cleaning up those short-lived objects.
However, what you need to keep in mind is that object allocation is a costly operation and when it comes to enterprise-grade performance you will eventually hit a bottleneck which might manifest itself as a performance issue.
Rule 8: Arithmetic Operations
Pay attention to what data types you are using for your calculations. It's very easy to use float and double to represent currencies but do you really need that many decimal places to represent currencies.
Keep in mind that loss of precision is still an issue in modern computers. Read the documentation on BigDecimal which is provided by Java for such operations as a convenience. BigDecimal forces you to use a rounding mode such that you do not end up with ambiguous results.
Rule 9: Modular design
Even if your application isn’t designed using Microservice architecture its a good idea to think about how your application can be broken up into smaller modules with what's available in Java.
However, if you use all the jdk libraries everywhere then this is not going to work for you. For example if your Rest API component just blindly imports everything in spring and whatnot, references cryptography, the filesystem, database and every jdk module that every lived then you will not be able to unbundle the JDK.
Try to use the principle of separation of concerns that comes from the Microservices doctrine. You might want to offload some of the functionality to other services in the ecosystem and communicate via API’s.
Rule 10: Threading and interrupts
More than 70% of the developers I interview do not know how threading works in Java. Neither do they know why there are other types of locks than ReantrantLock?
There is a difference between a synchronized block and a Lock. Unless you were programming before jdk 6 you might not have had to make the switch from using wait() -> notify() to Condition -> await().
If you are working on server-side code running many threads at once please make yourselves thorough on the java.util.concurrent package.
You may also like other Java articles
