1 |
--- |
2 |
Nothing to see here, move along. |
3 |
|
4 |
DEVELOPING | 71 +++++++++++++++++++++++++++++++++----------------------------- |
5 |
1 file changed, 38 insertions(+), 33 deletions(-) |
6 |
|
7 |
diff --git a/DEVELOPING b/DEVELOPING |
8 |
index 40b4ca2..1f5087a 100644 |
9 |
--- a/DEVELOPING |
10 |
+++ b/DEVELOPING |
11 |
@@ -1,37 +1,39 @@ |
12 |
Code Guidelines |
13 |
--------------- |
14 |
-A few code guidelines to try to stick to, please comment if none of these make |
15 |
-sense, they are pretty basic and mostly apply to old code. However for people |
16 |
-who are looking at current code, they make take up bad habits that exist in the |
17 |
-current codebase. |
18 |
+A few code guidelines to try to stick to, please comment if none of |
19 |
+these make sense, they are pretty basic and mostly apply to old code. |
20 |
+However for people who are looking at current code, they make take up |
21 |
+bad habits that exist in the current codebase. |
22 |
|
23 |
Python Version |
24 |
-------------- |
25 |
|
26 |
-Python 2.6 is the minimum supported version, since it is the first version to |
27 |
-support Python 3 syntax. All exception handling should use Python 3 'except' |
28 |
-syntax, and the print function should be used instead of Python 2's print |
29 |
-statement (from __future__ import print_function). |
30 |
+Python 2.6 is the minimum supported version, since it is the first |
31 |
+version to support Python 3 syntax. All exception handling should use |
32 |
+Python 3 'except' syntax, and the print function should be used instead |
33 |
+of Python 2's print statement (from __future__ import print_function). |
34 |
|
35 |
Dependencies |
36 |
------------ |
37 |
|
38 |
-Python and Bash should be the only hard dependencies. Any other dependencies, |
39 |
-including external Python modules that are not included with Python itself, |
40 |
-must be optionally enabled by run-time detection. |
41 |
+Python and Bash should be the only hard dependencies. Any other |
42 |
+dependencies, including external Python modules that are not included |
43 |
+with Python itself, must be optionally enabled by run-time detection. |
44 |
|
45 |
Tabs |
46 |
---- |
47 |
|
48 |
-The current code uses tabs, not spaces. Keep whitespace usage consistent |
49 |
-between files. New files should use tabs. Space is sometimes used for |
50 |
-indentation in Python code. Tab stop should for this reason be set to 4. |
51 |
+The current code uses tabs, not spaces. Keep whitespace usage |
52 |
+consistent between files. New files should use tabs. Space is |
53 |
+sometimes used for indentation in Python code. Tab stop should for this |
54 |
+reason be set to 4. |
55 |
|
56 |
Line-Wrapping |
57 |
------------- |
58 |
|
59 |
-Lines should typically not be longer than 80 characters; if they are an attempt |
60 |
-should be made to wrap them. Move code to the line below and indent once (\t). |
61 |
+Lines should typically not be longer than 80 characters; if they are an |
62 |
+attempt should be made to wrap them. Move code to the line below and |
63 |
+indent once (\t). |
64 |
|
65 |
errors.append(MalformedMetadata( |
66 |
errors.DESCRIPTION_TOO_LONG_ERROR % \ |
67 |
@@ -45,9 +47,10 @@ errors.append(MalformedMetadata( |
68 |
(length, max_desc_len), |
69 |
attr='DESCRIPTION.toolong') |
70 |
|
71 |
-The mixing of tabs and spaces means other developers can't read what you did. |
72 |
-This is why the python peps state spaces over tabs; because with spaces the line |
73 |
-wrapping is always clear (but you cannot convert spaces as easily as tabwidth). |
74 |
+The mixing of tabs and spaces means other developers can't read what you |
75 |
+did. This is why the python peps state spaces over tabs; because with |
76 |
+spaces the line wrapping is always clear (but you cannot convert spaces |
77 |
+as easily as tabwidth). |
78 |
|
79 |
Comparisons |
80 |
----------- |
81 |
@@ -78,9 +81,9 @@ Generally you can do two things here, if you are messing with defaults.. |
82 |
|
83 |
dict.get(foo, some_default) |
84 |
|
85 |
-will try to retrieve foo from dict, if there is a KeyError, will insert foo |
86 |
-into dict with the value of some_default. This method is preferred in cases where |
87 |
-you are messing with defaults: |
88 |
+will try to retrieve foo from dict, if there is a KeyError, will insert |
89 |
+foo into dict with the value of some_default. This method is preferred |
90 |
+in cases where you are messing with defaults: |
91 |
|
92 |
try: |
93 |
dict[foo] |
94 |
@@ -114,7 +117,8 @@ YES: |
95 |
NO: |
96 |
import os,sys,time |
97 |
|
98 |
-When importing from a module, you may import more than 1 thing at a time. |
99 |
+When importing from a module, you may import more than 1 thing at a |
100 |
+time. |
101 |
|
102 |
YES: |
103 |
from portage.module import foo, bar, baz |
104 |
@@ -139,9 +143,9 @@ NO: |
105 |
import sys |
106 |
|
107 |
Try not to import large numbers of things into the namespace of a module. |
108 |
-I realize this is done all over the place in current code but it really makes it |
109 |
-a pain to do code reflection when the namespace is cluttered with identifiers |
110 |
-from other modules. |
111 |
+I realize this is done all over the place in current code but it really |
112 |
+makes it a pain to do code reflection when the namespace is cluttered |
113 |
+with identifiers from other modules. |
114 |
|
115 |
YES: |
116 |
|
117 |
@@ -153,14 +157,15 @@ from portage.output import bold, create_color_func, darkgreen, \ |
118 |
green, nocolor, red, turquoise, yellow |
119 |
|
120 |
The YES example imports the 'output' module into the current namespace. |
121 |
-The negative here is having to use output.COLOR all over the place instead of |
122 |
-just COLOR. However it means during introspection of the current namespace |
123 |
-'green','red', 'yellow', etc. will not show up. |
124 |
+The negative here is having to use output.COLOR all over the place |
125 |
+instead of just COLOR. However it means during introspection of the |
126 |
+current namespace 'green','red', 'yellow', etc. will not show up. |
127 |
|
128 |
-The NO example just imports a set of functions from the output module. It is |
129 |
-somewhat annoying because the import line needs to be modified when functions |
130 |
-are needed and often unused functions are left in the import line until someone |
131 |
-comes along with a linter to clean up (does not happen often). |
132 |
+The NO example just imports a set of functions from the output module. |
133 |
+It is somewhat annoying because the import line needs to be modified |
134 |
+when functions are needed and often unused functions are left in the |
135 |
+import line until someone comes along with a linter to clean up (does |
136 |
+not happen often). |
137 |
|
138 |
|
139 |
Releases |
140 |
-- |
141 |
1.8.3.2 |