Pisilinux3/pisi
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

* express the concern about parenthetical expressions in more polite

Browse Source 
language
* additional recommendations and a link to PEP 8
* would still need reorg... most of those aren't guidelines, just suggestions.
This commit is contained in:
Eray Özkural
2005-10-26 21:29:58 +00:00
parent 4678b3c4b7
commit 4f68eff8ca
1 changed files with 35 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CODING
+35 -17
View File
@@ -4,28 +4,46 @@ Oooooo. "Coding Standards".
Guidelines Guidelines
---------- ----------
0. Before reading any further please observe
PEP 8: Style Guide for Python Code
http://www.python.org/peps/pep-0008.html
1. When using dirnames, don't expect the dir to end 1. When using dirnames, don't expect the dir to end
with a trailing slash, and please use the dirnames with a trailing slash, and please use the dirnames
in pisiconfig in pisiconfig. Use util.join_path instead of os.path.join
2. Python indentation is usually 4 chars. 2. Python indentation is usually 4 spaces.
3. Follow python philosophy of 'batteries included' 3. Follow python philosophy of 'batteries included'
4. Don't make the code have runtime dependencies on 4. Use exceptions, don't return error codes
a particular distribution (as much as possible) 5. Don't make the PISI code have runtime dependencies on
5. Don't assume narrow use cases. a particular distribution (as much as possible).
6. If you are changing something, check if that change 6. Don't assume narrow use cases. Allow for a mediocre
amount of generalization in your code, for pieces that
will be required later.
7. If you are changing something, check if that change
breaks anything and fix breakage. For instance a breaks anything and fix breakage. For instance a
name. Running the tests is not always enough! name. Running the tests is not always enough!
7. We all know, you're using LISP but didn't want to tell 8. A good design ensures separation of concerns. Every module
us. Don't scare, as a success story and for your encouregment has a specific documented responsibility. Don't make the
there are tens of people on somewhere with LISP releated jobs. horse clean your windows.
8. If you are studying Data structures and Algorithms, and if 9. To ensure readability avoid nesting python constructs
your first assignment is implementing a basic stack for more than 3 levels deep. Python is a good language (unlike C),
presedence, don't implement it. Just show your teacher the so you can define inner functions in a convenient way, use
syntax of LISP, tell him how beatifull it is, and show how can such decomposition techniques to break down your code into
otistic person can count lots of paranthesis with "one second" look, manageable chunks. The worst code you can write is one huge
probably you'll get A+. procedure that goes on for 1000 (or more) lines.
9. If you are interesting with "Playstation 2 Linux Games Programming" 10. Use a particular abstraction like a class or function only
or "How to extend C programs with Guile", please don't. if it makes sense. Don't just define things because they can
be defined. Define only things that will/may be used.
11. If you are doing an expensive task like searching through
10000 text chunks, please use an efficient data structure
and algorithm. We are not MS engineers who know no data
structure beyond doubly linked lists and no algorithm beyond
quicksort.
12. Resist the temptation to develop kludges and workarounds in
response to pressure. Take your time to solve the problems by
the book. The payoff comes later.
13. Same thing goes for premature optimizations. Knuth and Dijkstra
are watching over your shoulder. :)
Unit testing Unit testing
------------ ------------