|
1 | 1 | Contribution Guidelines |
2 | 2 |
|
3 | | -* Identifying or setting Engineering standards |
4 | | - * small as variable naming conventions |
5 | | - * General |
6 | | - * Names to be meaningful |
7 | | - * Classes |
8 | | - * try to avoid ‘name collisions’ ie: NotificationManager - this collides with a system provided class |
9 | | - * Must be meaningful. |
10 | | - * No classes named Test. |
11 | | - * conventions? |
12 | | - * Test classes for instance, CLASSNAMETest |
13 | | - * One test class per class |
14 | | - * for Visualforce |
15 | | - * controller vfpageController |
16 | | - * extension vfpageExtension |
17 | | - * Variables |
18 | | - * variable name have to be at least 3 characters |
19 | | - * should be descriptive |
20 | | - * |
21 | | - * Methods |
22 | | - * start with a verb? |
23 | | - * extend into testing |
24 | | - * Tests have to exist |
25 | | - * Tests have to pass before merge |
26 | | - * Test all logical paths, nulls, empty strings, lists, collections. |
27 | | - * feature pressure can delay test development, so tests are part of the feature! |
28 | | - * if you can test it, you should. |
29 | | - * comments! |
30 | | - * YES write comments. write WHY comments, not what? |
31 | | - * code smells |
32 | | - * code length |
33 | | - * Standard is loose - based on methods should do one thing. |
34 | | - * is it testable? does the method name make sense? does it do one thing? |
35 | | - * Rule of 9? 9 lines in a method, 9 methods in a class etc. |
36 | | - * Heuristics: |
37 | | - * methods should fit on one screen |
38 | | - * classes - should be focused on one thing |
39 | | - * order of info in a class: Class variables, constants, and Constructors, then public then private methods |
40 | | - * Simplifying conditionals and code length |
41 | | - * code quality |
42 | | - * no features without tests |
43 | | - * peer review? / code review |
44 | | - * No one likes to hear their baby’s ugly |
45 | | - * Per project? |
46 | | - * a standard is a foundation for the project: applied at beginning, or retroactively |
47 | | - * What can be automated, standards wise? |
48 | | - * Tooling: PMD, Prettier, etc. |
49 | | - * Can be revisited / refactored, but not necessarily mid-work. |
50 | | - * Laying them out vs. enforcing. |
| 3 | +- Identifying or setting Engineering standards |
51 | 4 |
|
52 | | - Credit : https://quip.com/ViKfAetuWBir |
| 5 | + - small as variable naming conventions |
| 6 | + - General |
| 7 | + - Names to be meaningful |
| 8 | + - Classes |
| 9 | + - try to avoid ‘name collisions’ ie: NotificationManager - this collides with a system provided class |
| 10 | + - Must be meaningful. |
| 11 | + - No classes named Test. |
| 12 | + - conventions? |
| 13 | + - Test classes for instance, CLASSNAMETest |
| 14 | + - One test class per class |
| 15 | + - for Visualforce |
| 16 | + - controller vfpageController |
| 17 | + - extension vfpageExtension |
| 18 | + - Variables |
| 19 | + - variable name have to be at least 3 characters |
| 20 | + - should be descriptive |
| 21 | + - |
| 22 | + - Methods |
| 23 | + - start with a verb? |
| 24 | + - extend into testing |
| 25 | + - Tests have to exist |
| 26 | + - Tests have to pass before merge |
| 27 | + - Test all logical paths, nulls, empty strings, lists, collections. |
| 28 | + - feature pressure can delay test development, so tests are part of the feature! |
| 29 | + - if you can test it, you should. |
| 30 | + - comments! |
| 31 | + - YES write comments. write WHY comments, not what? |
| 32 | + - code smells |
| 33 | + - code length |
| 34 | + - Standard is loose - based on methods should do one thing. |
| 35 | + - is it testable? does the method name make sense? does it do one thing? |
| 36 | + - Rule of 9? 9 lines in a method, 9 methods in a class etc. |
| 37 | + - Heuristics: |
| 38 | + - methods should fit on one screen |
| 39 | + - classes - should be focused on one thing |
| 40 | + - order of info in a class: Class variables, constants, and Constructors, then public then private methods |
| 41 | + - Simplifying conditionals and code length |
| 42 | + - code quality |
| 43 | + - no features without tests |
| 44 | + - peer review? / code review |
| 45 | + - No one likes to hear their baby’s ugly |
| 46 | + - Per project? |
| 47 | + - a standard is a foundation for the project: applied at beginning, or retroactively |
| 48 | + - What can be automated, standards wise? |
| 49 | + - Tooling: PMD, Prettier, etc. |
| 50 | + - Can be revisited / refactored, but not necessarily mid-work. |
| 51 | + - Laying them out vs. enforcing. |
| 52 | + |
| 53 | + Credit : https://quip.com/ViKfAetuWBir |
0 commit comments