Clean Code
What Is Clean Code?
When we talk about clean code, we talk about a reader-focused development style that produces software that’s easy to write, read, and maintain. Clean code is code that is easy to understand and easy to change.
Clearness
Best Practices
Maintenance
Easy to Test
Simplicity
Consistency
Optimisation vs. Readability
Always write code that is simple to read and which will be understandable for developers. Because time and resources that will be spent on hard readable code will be much higher than what you get from optimisation.
Structure your code such that its readable then it requires less comment s.
Avoid Obvious Comments
More comments means more to keep up to date
// get the country code
String countryCode = getCountryCode();
// if country code is US
if (countryCode == 'US') {
// return coutry code
return countryCode;
}Consistent indentation
Code should have an indentation of 4 characters
function myMethod() {
if(true){
doSomething();
} else {
doSomethingElse();
}
}Code Grouping & Code Spacing
Often the code in your methods can be arrange into a series of actions:
Get data
Filter data
Manipulate data
Return data
Adding a comment at the beginning of each block of code also emphasise the visual separation.
// get geo data
GeoData data = GeoDataAccess.get(recordId);
// create request
GoogleMapsRequest request = GoogleMapsFactory.createRequest(data);
// query google maps
GoogleMapsResponse response = GoogleApi.search(request);
// validate response
ValidateResponse(response);
return response;Avoid Deep Nesting
Too many levels of nesting can make code harder to read and follow. Change your code to reduce the level of nesting.
// bad
function Boolean eampleMethod(Id recordId) {
if (isAccessable(recordId)) {
if (idValid(recordId)) {
if (isEmpty(recordId)) {
if (canUpdate(recordId)) {
// do something
} else {
return false;
}
} else {
return false;
}
} else {
return false;
}
} else {
return false;
}
}Pick One Word per Concept
Pick one word for one abstract concept and stick with it.
For instance, it’s confusing to have fetch, retrieve, and get as equivalent methods of different classes.
Variables
Naming
Use Camel Case: First letter of each word is capitalised, except the first word.
Integer numOfRecords = 10;Length
Avoid shorten variable names
// bad
OpportunityListItem oli;
Id acId;
// good
OpportunityListItem lineItem;
Id accountId;Arrays or Lists
Pluralisation of the variable name makes sense or appending List
// bad
List<Account> accs;
List<Account> account;
List<Account> data // too generic
List<Account> list; // no context
// good
List<Account> accounts;
List<Account> activeAccounts;
List<Account> accountList;Boolean
Boolean's can hold only 2 values, true or false. Given this, using prefixes like is, has, and can will help the reader infer the type of the variable.
// bad
Boolean open = true;
Boolean write = true;
Boolean fruit = true;
// good
Boolean isOpen = true;
Boolean canWrite = true;
Boolean hasFruit = true;Numbers
For numbers, think about words that describe numbers.
Prefix words like max, min, numOf or total
// bad
Integer accounts = 3;
// good
Integer minAccounts = 1;
Integer maxAccounts = 5;
Integer numOfAccounts = 5;
Integer totalAccounts = 3;Constants
Use upper case with under scores:
final Decimal TAX_RATE = 0.2;Use pronounceable names and searchable names
When a name is pronounceable mostly it is searchable and searchable names is a must to enhance find operations in refactoring. Avoid using a single letter named variable.
// bad
Date d;
Time t;
DateTime dt;
// good
Date birthday;Function names should be verbs
Last updated