-
Notifications
You must be signed in to change notification settings - Fork 26
/
conventions
168 lines (88 loc) · 4.81 KB
/
conventions
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
------ Python ------
Naming Conventions
Methods:
Methods will be named with a camel case but with the first letter always in capital. It is always a good practice to club similar functions together and place them one after the other. For example,
def ProcessArgument(argument):
return processedArgument
Variables:
These will also be named with a camel case, but for variables, you will always be starting them with small letter. For example,
isArgumentProcessed = False
Classes:
Same as methods.
DJANGO SPECIFIC
Model Classes:
Classes:
Names of the classes in the models are essentially the names of Tables. Tables should always start off with a capital letter followed by camel casing.
Methods:
Methods in this case will be inside the Class, hence you will follow the same conventions as of the Vanilla Python.
Variables:
Variables in this case are the actual elements which are
Indentation
Tabs, always use tabs. Don't use spaces. Spaces are horrible.
Layout
Exception Handling / Logging
Use the format:
variable = None
try:
one_line_execution
except:
pass or return with error
Commenting
Use # to comment above the line mentioned.
Write the comment in all small letters to maintain consistency.
Label sections of functions, while making sure they are similar.
---------------
Javascript
Naming Conventions
Methods:
Methods will be named with a camel case but with the first letter always in capital. It is always a good practice to club similar functions together and place them one after the other. For example,
function ProcessArgument(argument):
return processedArgument
Variables:
These will also be named with a camel case, but for variables, you will always be starting them with small letter. Always use 'var' to initialize a new Variable. For example,
var isArgumentProcessed = False
Classes:
Same as methods.
DJANGO SPECIFIC
Model Classes:
Classes:
Names of the classes in the models are essentially the names of Tables. Tables should always start off with a capital letter followed by camel casing.
Methods:
Methods in this case will be inside the Class, hence you will follow the same conventions as of the Vanilla Python.
Variables:
Variables in this case are the actual elements which are
Indentation
Tabs, always use tabs. Don't use spaces. Spaces are horrible.
Layout
Exception Handling / Logging
Use the format:
variable = None
try:
one_line_execution
except:
pass or return with error
Commenting
Use # to comment above the line mentioned.
Write the comment in all small letters to maintain consistency.
Label sections of functions, while making sure they are similar.
JSON
HTML
CSS
C#
Naming Conventions
How will you name your methods, variables, classes and interfaces? Which notation will you be using?
Also something else included in our standards was a split off standards for SQL, so we had similar names for tables, procedures, columns, id fields, triggers, etc.
Indentation
What will you be using for indentation? A single tab? 3 spaces?
Layout
Will braces be kept on the same line as the opening method line? (generally java) or on the next line or a line of its own? (generally C#)
Exception Handling / Logging
What are your standards for exception handling & logging, is it all home grown or are you using a third party tool? How should it be used?
Commenting
We have standards to dictate grammatical correctness, and that comments begin on the line before, or after, not on the same line, this increases readability. Will comments have to be indented to the same depth as the code? Will you accept those comment borders used around larger texts?
How about the \\\ on Methods for descriptions? Are these to be used? When?
Exposure
Should all of your methods and fields be implementing the lowest level of access possible?
Also an important thing to note. A good standards document can go a long way in helping review code, does it meet these minimum standards?
I've barely scratched the surface of what can go into one of these documents, but K.I.S.S.
Don't make it long, and boring, and impossible to get through, or those standards just wont be followed, keep it simple.