Skip to content

Java, let me follow code style

Reading Time: 5 minutes

Developers spend much more time reading the code rather than writing. For that reason readability and “clean code” practices are in general is very important. There is a lot of different rules exists to help developers structure their code in a way so it needs less effort for understanding and in maintenance. On top, there are also tools created to enforce those rules.

Now to the code. Looking at it from the high-level perspective it is easy to distinguish bigger blocks, like classes (not necessarily to follow the OOP paradigm, by “class” any top-level grouping can be mentioned) and their members. And the order of these members in class is very important.

There is a couple of most popular recommendations to that.

First one, it comes from the code style guidelines published by big tech players like Google or Oracle says that it is important to order class members by the level of exposure. This order fits good the code written in the form of a library:

  • public members – class API, is the most important part, must fall into consumer’s eye as soon as possible so it stands at the first position;
  • protected members – internal API, still important as it can be overridden thus needs to be at the second position;
  • private members – pure internals, can be placed at the very last position.

An alternative recommendation suggested by Robert C. Martin can be formulated much more easily: order of the members must be defined like chapters in the fiction book, they must follow the execution flow “story” and explain the code without a need to jump around the text up and down. This style fits good typical services that define pure business logic, set of operations required to execute some user scenario.

So for the second approach there is not much what can be automatically enforced, whereas for the first one it is an opposite situation. But even if the idea is simple, sometimes it is just impossible to overcome language limitations and entirely follow the code style “public” -> “protected” -> “private”.

Problem in Java

Here is a simple example in Java (it is an attempt to build a path on a file system via two different ways: combining class-level constants versus combining method calls with hardcoded strings):

public class StorageConfiguration {

    public static final String DIR_A = ROOT_FOLDER + "A";
    private static final String ROOT_FOLDER = "~/";

    public static String getDirA() {
        return getRoot() + "A";

    private static String getRoot() {
        return "~/";

    public static void main(String[] args) {


But as it turns out this code is not compilable.

The compiler complains about the usage of constant ROOT_FOLDER (and there is no problem with combining methods):

Error:(3, 40) java: illegal forward reference

The reason for that is explained in Java spec 1 :

Use of class variables whose declarations appear textually after the use is sometimes restricted … it is a compile-time error if …:

  • The use is not on the left hand side of an assignment;

Problem in C#

Ok, Java has limitations, so it worth to be compared with some alternative. Similar code in C# looks like this:

public class StorageConfiguration
    public static readonly string DIR_A = ROOT_FOLDER + "A";
    private static readonly string ROOT_FOLDER = "~/";

    public static String getDirA()
        return getRoot() + "A";

    private static String getRoot()
        return "~/";
    public static void Main()
And at first glance it looks fine and gives no compilation errors. But! It silently hides unexpected behavior. The output of the code above is the following:


Both examples show some specifics of each language. In general, it is very important to know them, but fail-fast (Java case) is always a better alternative as opposed to implicit behavior (C# case).



Published inJava

Be First to Comment

Leave a Reply

We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.