Vladimir Romanov - How to write code that is easy to read and change? What should you do when you see a piece of code written years ago which is hard to understand? In my experience, this boils down to 4 principles that I would like to share along with some examples in Apex

1. CLEAN CODE PRINCIPLES
VLADIMIR
ROMANOV

2. #YeurDreamin2019
About me
• Salesforce Platform Developer
• Hanging out in the cloud since 2014
• Big and small projects
• Currently based in Berlin (SumUp)
Vladimir Romanov

3. SAFE HARBOR…

4. #YeurDreamin2019
WHAT IS CLEAN CODE?
• Human Readable
• Easy to change and maintain

5. #YeurDreamin2019
Messy code

6. #YeurDreamin2019
CLEAN CODE PRINCIPLES
0. The Boy Scout rule
1. Meaningful Naming
2. Constants instead of Hard-Coded Strings or Integers
3. Small Functions

7. #YeurDreamin2019
BOY SCOUT RULE
• Always leave the campground cleaner than you found it. (Boy Scouts)
• Always leave the code you’re editing a little better than you found it.
(Robert C. Martin)
 Take responsibility of the environment
 There is no ideal code – there is better code
=

8. #YeurDreamin2019
#1 MEANINGFUL NAMING
• Descriptive, Intention-Revealing
• Use words, not abbreviations
 Better long than ambiguous
• Searchable
a -> accountRecord
genymdhms -> generationTimestamp

9. #YeurDreamin2019
Slide title
• First level 1
 Second level 2

10. #YeurDreamin2019
Descriptive Names
• Class Names
 Noun or noun phrase like Customer, WikiPage
 Avoid generic words like Manager, Processor, Data, Info
• Method Names Should Say What They Do
 verb or verb phrase names like postPayment, deletePage, or save.
 doRename() -> renamePage(), renamePageAndOptionallyAllReferences()

11. #YeurDreamin2019
Naming considerations
• Having variable type as part of name
 Account parentAccount;
 Button resetButton;
• Using plural names for arrays/collections of objects
 List or Set can be omitted if sets usually contain unique primitive type
values and lists contain non-unique complex objects
 userList -> users
 List<FollowUp__c> followUps;
 Set<Id> accountIds;

12. #YeurDreamin2019
Naming considerations
• Define and follow a Naming convention per project, for example:
 Use CamelCase (sendSMS -> sendSms)
 Variable and method names start with lowercase letter (accountRecord,
accounts)
 Class names start with uppercase letter (Account)
 Constants written in uppercase separated with underscore
(DAYS_IN_WEEK, SOBJECTTYPE_CASE, STR_OK)

13. #YeurDreamin2019
Naming considerations
• Re-evaluate names as software evolves
• Respect Encapsulation
 Add public access or {get;set;} only when necessary. Use private
variables by default.
 Private variables are easier to change – they are referenced only inside
the class

14. #YeurDreamin2019
Naming considerations
• Use variables as a way to say more about what the code is doing
• Break the calculations up into intermediate values that are held in
variables with meaningful names.
Matcher match = headerPattern.matcher(line);
if(match.find()) {
String key = match.group(1);
String value = match.group(2);
headers.put(key.toLowerCase(), value);
}

15. #YeurDreamin2019
#2 CONSTANTS INSTEAD OF HARD-CODED STRINGS OR INTEGERS
• Use constant variables instead of hardcoded Strings or Numbers
 DAYS_IN_WEEK instead of 7
 COMPANY_CODE_ITALY instead of ‘485’
• Give them a descriptive name using UPPER CASE
• Define all the constants at the top of the class
• Consider using a class to contain global constants.
• Consider getting value for constants from Custom Labels or Custom
Metadata
• Easier to
 Read
 Search
 Change value
 Test

16. #YeurDreamin2019
#3 SMALL FUNCTIONS
• Use Small Functions – split a larger function into smaller ones by
looking at
 logical sections
 levels of indentation
 Rule of thumb - Every Function should do One thing and do it well
 Does one thing
 Separates levels of abstraction
 Easier to
 Understand
 Modify
 Reuse, reduce duplication
 Test
• The less arguments the better (ideally <= 2)
 Use instance / static variables to pass frequently used data
 Use DTO classes to encapsulate parameters – e.g. InitDataDto,
AddressWrapper, RequestWrapper

17. #YeurDreamin2019
Applying the principles - Clean Conditionals
• Encapsulate conditionals
 if (timer.hasExpired() && !timer.isRecurrent()) -> if (shouldBeDeleted(timer))
• Encapsulate boundary conditionals
 level + 1 < tags.length -> if(nextLevel < tags.length)
• Avoid Negative Conditionals
 if ( !followUpNeeded() ) -> if ( followUpNotNeeded() )
• Use standard apex methods for null checks and empty lists checks
 myString != null && myString!=‘’ -> String.isNotEmpty(myString)
 myList.size()==0 -> myList.isEmpty()
 $A.util.isEmpty(value) – in Lightning components

18. #YeurDreamin2019
Applying the principles - Clean SOQL
• Format SOQL queries
• Use a separate function for each SOQL query, adding all fields on
separate lines in the alphabetical order
• Place the function at the end of class or use a Data Access Layer class to
reuse queries
 allows to reuse it
 Easier to add fields
 Better maintenance
private static List<Account> retrieveAccountsByIds (Set<Id>
accountIds)
{
return
[
SELECT
Id,
Name
FROM Account
WHERE Id IN :accountIds
];
}

19. #YeurDreamin2019
Applying the principles - Clean Loops and Branches
• Keep indentation at max 2 levels
• an if else chain inside a function may mean it is doing more than one thing
• Too many branch levels may mean working on different levels of
abstraction, which makes harder to read and easier to miss something
• Use loop control statements like break; and continue; statements to
reduce indentation
for (WRP_Email emailWrapper : emailWrappers) {
if (emailWrapper.hasPropertyRequest()) {
Id plotId = getPlotIdFromEmail(emailWrapper);
if (plotId!= null)
plotIds.add(plotId);
}
}
->
for (WRP_Email emailWrapper : emailWrappers) {
if (emailWrapper.hasNoPropertyRequest())
continue;
Id plotId = getPlotIdFromEmail(emailWrapper);
if (plotId!= null)
plotIds.add(plotId);
}

20. #YeurDreamin2019
Applying the principles - Clean comments
• Clean code often doesn’t need comments!
 Don’t use trivial/redundant comments
 Delete outdated comments when software evolves (saving them in git
repository)

21. #YeurDreamin2019
Applying the principles - Clean debugging
• Write class name and method name in debug message
 System.debug(‘MyClass::myFunction()::myVariable: ’+myVariable);
 No need to add the message when names reveal the intention of the class, function and the variable.
 Easier to search in debug log
 Works best when functions are small

22. SHOW ME MORE CODE!

23. #YeurDreamin2019
CHANGE OF VISION
• By applying the Clean Code Principles you can See how you can improve
the code and you can do it as you go!

24. #YeurDreamin2019
Further reading and watching
• Book - Clean Code (Robert C. Martin)
 https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
• Pluralsight courses:
 Clean Code: Writing Code for Humans (Cory House)
 https://app.pluralsight.com/library/courses/writing-clean-code-humans
 Maximize Your Value through Salesforce Coding Best Practices
(Matt Kaufman and Don Robins)
 https://app.pluralsight.com/library/courses/play-by-play-maximize-value-through-salesforce-coding-best-
practices/table-of-contents

25. CODE REVIEW CHALLENGE!
• Make groups of 2-3 people
• Set date and time when you will do a code review together
• Bring some of your code
• Discuss what contributes to readability and maintainability

26. #YeurDreamin2019
Join us for drinks
@18:00 sponsored
by
Community sponsors:
Stay in touch!
• LinkedIn https://www.linkedin.com/in/vladimir-romanov/
• Twitter @vladfromrome
• YeurDreamin Slack #clean-code
NonProfit-track sponsor: