Keeping your code clean is no easy task. Clean code allows your project to pass the test of time. It can be broken down into making your code simple to read, write, and understand. This post will explain how you can clean up your class fields to move towards a cleaner project.
Code maintenance is a full time job. It’s important to clean up your code as you go, so that you don’t leave yourself a mountain of [technical debt](https://en.wikipedia.org/wiki/Technical_debt) to purge later on. Think of yourself as a lazy developer, better to clean code now so you don’t need to do more work later! The other reason to keep on top of your codebase is the _’broken window theory’_.
> maintaining and monitoring urban environments to prevent small crimes such as vandalism, public drinking, and toll-jumping helps to create an atmosphere of order and lawfulness, thereby preventing more serious crimes from happening. [[1]](https://en.wikipedia.org/wiki/Broken_windows_theory)
Using broken window theory gives us a real boost to our reasoning for cleaning up the class fields. Class fields (also referred as [member variables](https://en.wikipedia.org/wiki/Member_variable)) are the first thing (_potentially_) a developer will see when reading the code of a class. Let’s start off well and make sure they are: _simple to read, simple to add to and simple to understand_.
## Getting insight into ‘modifiers’
_The examples discussed and given below are based on Java, but the theory and takeaway can be applied to any language._
Class fields can have 3 different types of modifiers. You use different combinations of these modifiers for different things. I’ve noticed we use some combinations a lot more than others and this usage rate can affect the definition of clean class fields.[1](#footnote1)
The first type of modifier are the access modifiers. `Public`, `Protected`, `”`(_Default/Package_) and `Private` these affect the scope of your field. Going from most accessible or most visible to the least respectively.
**Knowing the access modifier of a variable is important because it gives you some more understanding about the [coupling](https://en.wikipedia.org/wiki/Coupling_(computer_programming)) of a class.** Does this class share its data? Is it expected to work in conjunction with other classes? Is it attempting to be [open for extension](https://en.wikipedia.org/wiki/Open/closed_principle)? Does it have a declared public interface?
The `static` modifier is for declaring a field working at the class scope (1 per class definition) instead of at the instance scope (1 per instance).
The `final` modifier effects the immutability of a class field. Final class fields can be set once at construction and then their reference can not change, i.e. [immutable](https://en.wikipedia.org/wiki/Immutable_object).
**Knowing if a field is static or final gives you more understanding about the behaviour of the class as a whole.** Is the class expected to act alone? Does it want to use caching? Does it hold state or change over time?
## Clean by order
Now that we have a shared understanding of the different modifiers let’s show a potential _clean_ ordering. What do you think of this[3](#footnote3):
“`java
public static final
private static final
protected final
private final
private
“`
From our shared understanding, **this ordering for our class fields declares the most accessible at the top** (_the most shared_) **to the least accessible** (_and only for us_) **at the bottom.** The public variables come first, then the protected then the private. The immutable final variables come first then the mutable non final variables which can be changed at any point in the class.
It’s important to also notice what is not written i.e. space (ie: blank lines) is important here to show clear separation and [data clumping](https://martinfowler.com/bliki/DataClump.html) of different types as discussed. To keep the code clean here it’s important to not add extra blank lines when more fields of any one type are added. [2](#footnote2)
## Examples over theory
As worked examples, your class could look like one of these:
A:
“`java
public static final String EXTRA_ID = “com.foo.EXTRA_ID”;
public static final String EXTRA_NAME = “com.foo.EXTRA_NAME”;
private static final int MAX_RETRIES = 3;
private final FooCatcher fooCatcher;
private final BarService barService;
private int attempts = 0;
“`
B:
“`java
private static final int RESULT_CODE = 123;
private final Basket basket;
private final WishList wishlist;
private final AdvertDisplayer advertDisplayer;
private final AnalyticsService analyticsService;
“`
C:
“`java
public static final String TAG = “some tag for droidz”;
public static final String COL_ID = “id”;
public static final String COL_NAME = “name”;
private static final TAG_CACHE = TagCache.newInstance();
protected final TagManager tagManager;
protected final DatabaseAccess dbAccess;
private int lastAccessId;
“`
## Conclusion
Keeping your code always in this ordering and having this shared understanding allows you to easily:
* visualise potential behaviour
* see the public api
* understand scope
* infer coupling
* accept dependencies
* acknowledge state
I hope that gives you some inspiration to start looking at the smaller parts of your code base to help you move towards cleaner code. Explaining broken window theory through code, if you get your code base into the right state (_clean_) at the small components then the rest will fall in line. Good luck!
______
1: We won’t talk about `transient`, `synchronised` or `volatile` as these are only used on rare occasions, but you can factor them into the below quite easily when necessary.
2: Some combinations are missing for example `public final` or `protected`, this is because for reasons we’re not going to go into in this blog they’re bad practice.
3: Some assumed knowlege here is the Java convention for class ordering https://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html