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