5 Simple Rules for Organizing Your Apex Code

When you start to write code many programmers just start writing to get the project done. Honestly, I’ve done it. My code still works even if it doesn’t look good and so does yours. The compiler doesn’t need it to look nice and structured or organized in order to compile it, and the web browser doesn’t need it to look a certain way either.

So why organize your code?

I’ve started many projects where previous code had been written and I’m adding new functionality or fixing old broken code. You may have experienced this too as a developer. You start getting into the code and it’s a nightmare! Before you can even start your project you have to parse through the old code, and even start formatting it and organizing it so that it’s readable and understandable for yourself so that you can then start looking at the changes that need to be made to it.

We organize our code to reduce the effort needed to read and understand source code, to enable code reviews to focus on more important issues than syntax and naming standards.

Here are 5 simple rules for organizing your code:

The Name of a Class Should Always Communicate It’s Purpose

When you give a class a name, it should be a meaningful representation of what the class is describing. Class names should be simple and descriptive and it’s always a good practice to make the class name a noun. It’s often a good coding practice to use the upper case camel hump convention (i.e. MyApexClass). When writing a test class, you should always use the same name as the class, but then suffix it with “_UT” or “_Test”.

One Trigger Per Object and Always use a Handler Class

In order to control order of operations you MUST use the best practice of only having one trigger per object. I’ve seen many instances where there were multiple triggers on an object like “UpdateContactWithAccount” and “UpdateContactAfterCase” as two examples. If both of these are triggers, then you will have no way of knowing which executes first.

Instead, you should have only one trigger that holds the flow of the logic and then you can have multiple classes that it refers to.

So instead of having:

 
Trigger UpdateContactWithAccount on Contact (before insert){
       // execute logic
}

Trigger UpdateContactAfterCase on Contact (before insert){
       // execute logic
}

You would have just one trigger that looks at the incoming events and does a hand off of the relevant data to other classes:

 
Trigger ContactTrigger on Contact (before insert){
    if(Trigger.isBefore && Trigger.isInsert){
        UpdateContactWithAccount.updateContact(Trigger.new);
        UpdateContactAfterCase.updateContact(Trigger.new);
    }
}

Make Your Methods Simple and Descriptive

It’s always better to make your methods short and descriptive to help with readability and understanding. The more descriptive your method names and variable names are the less need there is for commenting.

Another good practice is to use verbs in the method names whereas with class names you use nouns. You should also use camel hump naming conventions with method names as well to help with readability and understanding. Using a strong active verb as the first word is helpful to know what the method is doing (i.e. update, remove, delete, clear, reset, load, get, etc).

Incorporate Meaningful Comments

Comments indicate the intention of the code and can also communicate business processes and implementation decisions that were made. This is helpful to have in the code so that later on that information can be tied to particular lines of codes.

Some common helpful comments are:

• A Comment Header: This is usually at the top of a page and provides the overall purpose of the code in this page, the author’s name, date and any revisions made.
• A Comment Prior to Each Method/Function: You would include the purpose of this method and any input parameters and return types. You could also include any dependencies and author and date.
• Inline Comments: These comments can be sparse throughout the code in order to provide clarity to any complex functionality. These can be very helpful in loops and conditions where the logic can get very complex.

Usually less comments are better and there is no need to comment every line, but only when you have great descriptive names for your methods, variables and such. But when things start to get complex, having comments in the code is very helpful.

Indentation and Spacing

Lastly, we have indentation and spacing. No one likes to read code that is bunched up together as one solid paragraph with no indentions. Indentions and spacing are essential to making readable and understandable code. Your code may still work without this, but you will make it a nightmare to maintain for the developers who come behind you.

There are many indentation styles, but it helps to be consistent throughout your code.

Here is a sample Style Guide you can use for Apex:

https://nimbleuser.github.io/apex-style-guide/

You can see a list of various indentation styles here:

https://en.wikipedia.org/wiki/Indentation_style