|
| 1 | +# Polaris Apex Style Guide # |
| 2 | +[TOC] |
| 3 | +##Intro## |
| 4 | + |
| 5 | +###Goals### |
| 6 | +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 | + |
| 8 | +1. New and old developers, and outside contractors of all sorts can easily read, understand and maintain our growing code base. |
| 9 | +2. Code merges are easy to handle and are content-ful, not style-ful. |
| 10 | + |
| 11 | +See the Internet for more arguments about why style guides are important and useful things and not just a waste of time. |
| 12 | + |
| 13 | +###Sources### |
| 14 | +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 | + |
| 16 | +This is still a living document and I'm happy to make changes. |
| 17 | + |
| 18 | +##Basics## |
| 19 | +###Special characters### |
| 20 | +####Whitespace#### |
| 21 | +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 | + |
| 23 | +####Special escape sequences#### |
| 24 | +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 | + |
| 26 | +####Other Non-ASCII Characters#### |
| 27 | +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 | + |
| 29 | + > Tip: In the Unicode escape case, and occasionally even when actual Unicode characters are used, an explanatory comment can be very helpful. |
| 30 | +
|
| 31 | +##Structure## |
| 32 | + |
| 33 | +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 | + |
| 35 | +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 | + |
| 37 | + |
| 38 | +###Indentation### |
| 39 | +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 | + |
| 41 | +Open braces should have a space before them and not a newline. The matching close brace should line up with the start of the opening brace's line. |
| 42 | + |
| 43 | +`else`s and `else if`s do not get a newline before them. Neither do `catch`es or `while`s in a `do...while` loop. |
| 44 | + |
| 45 | +E.g.: |
| 46 | +``` |
| 47 | +public void foo(Integer bar) { |
| 48 | + if(bar == 3) { |
| 49 | + return; |
| 50 | + } else if(bar > 7) { |
| 51 | + List<Integer> wasteOfSpace = new List<Integer>(); |
| 52 | + do { |
| 53 | + wasteOfSpace.add(8); |
| 54 | + } while(wasteOfSpace.size < 5); |
| 55 | + } else { |
| 56 | + upsert v; |
| 57 | + } |
| 58 | +} |
| 59 | +``` |
| 60 | + |
| 61 | +All `if`, `while` and `for` statements must use braces even if they control just one statement. |
| 62 | + |
| 63 | + |
| 64 | + |
| 65 | + |
| 66 | + |
| 67 | + |
| 68 | +> Written with [StackEdit](https://stackedit.io/). |
0 commit comments