You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal of this style guide is like that of any other style guide. Everyone has their own ideas of what makes code pretty. As long as there's some logic behind that beauty, no one is right or wrong. But it's important to have a standard so that:
7
33
8
34
1. New and old developers, and outside contractors of all sorts can easily read, understand and maintain our growing code base.
9
35
2. Code merges are easy to handle and are content-ful, not style-ful.
10
36
11
37
See the Internet for more arguments about why style guides are important and useful things and not just a waste of time.
12
38
13
-
###Sources###
39
+
<aname="sources"></a>
40
+
### Sources
14
41
Since Apex is largely a Java and C# spin-off, I am largely relying on [Google Java Style Guide](http://google-styleguide.googlecode.com/svn/trunk/javaguide.html) first, then C# where those do not apply. And some is just pulled out of my own opinions.
15
42
16
43
This is still a living document and I'm happy to make changes.
17
44
18
-
##Basics##
19
-
###Special characters###
20
-
####Whitespace####
45
+
<aname="basics"></a>
46
+
## Basics
47
+
<aname="special-characters"></a>
48
+
### Special characters
49
+
<aname="whitespace"></a>
50
+
#### Whitespace
21
51
The only permissible whitespace characters in source code are newline and space (0x20). Inside of a string literal, only a space is allowed. Line must not end with spaces (`/ +$/` must not match anything in the file). Classes should all end with a newline.
22
52
23
-
####Special escape sequences####
53
+
<aname="special-escape-sequences"></a>
54
+
#### Special escape sequences
24
55
For any character that has a special escape sequence (`\b`, `\t`, `\n`, `\f`, `\r`, `\"`, `\'` and `\\`), that sequence is used rather than the corresponding octal (e.g. `\012`) or Unicode (e.g. `\u000a`) escape.
25
56
26
-
####Other Non-ASCII Characters####
57
+
<aname="other-non-ascii-characters"></a>
58
+
#### Other Non-ASCII Characters
27
59
For the remaining non-ASCII characters, either the actual Unicode character (e.g. `∞`) or the equivalent Unicode escape (e.g. `\u221e`) is used, depending only on which makes the code easier to read and understand.
28
60
29
61
> Tip: In the Unicode escape case, and occasionally even when actual Unicode characters are used, an explanatory comment can be very helpful.
30
62
31
-
##Structure##
63
+
<aname="structure"></a>
64
+
## Structure
32
65
33
66
The ordering of the members of a class can have a great effect on learnability, but there is no single correct recipe for how to do it. Different classes may order their members differently.
34
67
35
68
What is important is that each class order its members in some logical order, which its maintainer could explain if asked. For example, new methods are not just habitually added to the end of the class, as that would yield "chronological by date added" ordering, which is not a logical ordering.
36
69
37
-
38
-
###Indentation###
70
+
<aname="indentation"></a>
71
+
###Indentation
39
72
All blocks of code should be indented with 2 spaces. Spaces, not tabs, to ensure that it looks the same on everyone's screen and doesn't waste horizontal space.
40
73
41
-
###New-lines and spaces###
74
+
<aname="new-lines-and-spaces"></a>
75
+
### New-lines and spaces
42
76
Use vertical whitespace as appropriate. Don't be afraid to separate blocks of code.
43
77
44
78
Prefer placing comments on a line by themselves.
@@ -53,7 +87,7 @@ In method definitions, there should be no space before the open parenthesis, and
53
87
54
88
In method calls and definitions, there should not be whitespace between the name of the method and the open parenthesis.
55
89
56
-
A single space should separate binary operators from the surrounding elements (e.g., `+`, `||`, `=`). Unary operators (`!`, `-`) should be attached to their parameters. A colon inside a `for each` loop (e.g., `for (Contact cnt : contacts) {`) should have one space on either side.
90
+
A single space should separate binary operators from the surrounding elements (e.g., `+`, `||`, `=`, `>=`). Unary operators (`!`, `-`) should be attached to their parameters. A colon inside a `for each` loop (e.g., `for (Contact cnt : contacts) {`) should have one space on either side. There should be no whitespace before commas, and one space after (e.g., `System.debug(LoggingLevel.INFO, 'fsdfs');`).
57
91
58
92
If using C#-style properties, code should follow the following rules:
59
93
@@ -62,22 +96,25 @@ If using C#-style properties, code should follow the following rules:
62
96
* If there is logic, there should be a new-line before each open-brace, and before and after each closed-brace.
63
97
* If one clause has logic and one does not, place the clause without logic on its own line.
64
98
65
-
### Prefer Explicit Declarations ###
99
+
<aname="prefer-explicit-declarations"></a>
100
+
### Prefer Explicit Declarations
66
101
Always specify:
67
102
68
-
* public/private modifiers
69
-
* with/without sharing
103
+
*`global`/`public`/`private` modifiers - prefer `private`, and if possible, `static`
104
+
*`with sharing`/`without sharing`
70
105
*`this` when calling local methods or setting local members/properties.
71
106
72
-
### Capitalization ###
107
+
<aname="capitalization"></a>
108
+
### Capitalization
73
109
74
110
We follow the Java standard of capitalization with the listed exceptions. That means that statements (`for`, `if`, etc.) should be lowercase, constants should be `UPPER_CASE_WITH_UNDERSCORES`, classes and class-level variables should be declared as `UpperCamelCase`, and methods, parameters and local variables should all be declard as `lowerCamelCase`.
75
111
76
112
Native Apex methods and classes should generally be referenced as written in official Salesforce documentation. This means that schemas and classes are `UpperCamelCase` and methods are `lowerCamelCase`. The only deviation from this rule is `SObject` which should be written as such (in the documentation, it is usually written `sObject` which does not conform to this style guide and should not be used).
77
113
78
114
However, when referencing any metadata (SObject, SObjectField, FieldSet, Action, Class, Page, etc.), use the declared capitalization. When referencing a method, field, etc., that is not capitalized according to these rules, use the declared capitalization.
79
115
80
-
### Example ###
116
+
<aname="example"></a>
117
+
### Example
81
118
82
119
```
83
120
public class MyClass {
@@ -106,13 +143,14 @@ public class MyClass {
106
143
107
144
public void foo(Integer bar) {
108
145
if (bar == 3) {
109
-
System.debug(debugCode(bar) + ' - hi there!');
146
+
// Diane often asks when bar is 3.
147
+
System.debug(this.debugCode(bar) + ' - hi there!');
110
148
return;
111
149
} else if (bar > 7) {
112
150
List<Integer> wasteOfSpace = new List<Integer>();
113
151
do {
114
-
wasteOfSpace.add(this.calculatedInteger);
115
-
} while (wasteOfSpace.size < 5);
152
+
wasteOfSpace.add(this.calculatedInteger);
153
+
} while (wasteOfSpace.size() < 5);
116
154
} else {
117
155
try {
118
156
upsert v;
@@ -130,13 +168,14 @@ public class MyClass {
130
168
```
131
169
132
170
133
-
##SOQL##
171
+
<aname="soql"></a>
172
+
## SOQL
134
173
135
174
In general, SOQL should be declared inline where it is used. In some cases, like when referencing FieldSets, it's necessary to build SOQL queries dynamically. The same rules will generally apply.
136
175
137
176
SOQL keywords (e.g., `SELECT`, `WHERE`, `TODAY`) should always be written in `ALL CAPS`. Objects, fields and bind variables should be referenced as declared. Each clause of the SOQL Query should be on its own line so that finding what changed in a diff is easier. That is, each `SELECT`, `FROM`, `WHERE`, `AND`, `OR`, `GROUP BY`, `HAVING`, `ROLL UP`, `ORDER BY`, etc., with the exception of the first `SELECT` should start a new line. That line should start in the same column as the most relevant `SELECT`.
138
177
139
-
Long lists of fields in a `SELECT` clause should be ordered in a logical manner and broken to fit within page width, with subsequent lines aligned with the first field. Always select `Id` first.
178
+
Long lists of fields in a `SELECT` clause should be ordered in a logical manner and broken to fit within page width, with subsequent lines aligned with the first field. Always select `Id`, and always select it first.
Name a class or trigger after what it does. Triggers should be verbs and end with `Trigger` (e.g., `SyncCaseToplineWithDescriptionTrigger`). Controllers and Controller Extensions should end with the word `Controller`.
200
+
201
+
<aname="methods"></a>
202
+
### Methods
203
+
Methods should all be verbs. Getters and setters should have no side effects (with the exception of setting up cached values and/or logging), and should begin with `get` or `set`.
155
204
205
+
<aname="test-classes"></a>
206
+
### Test classes
207
+
Test classes should be named `TEST_ClassUnderTest`. If the test is not a unit-level test but instead a broader test case, it it should be named `TEST_StuffThatsGenerallyBeingTested`.
0 commit comments