Coding Style
Programs must be written for people to read, and only incidentally for machines to execute. -- Abelson & Sussman, Structure and Interpretation of Computer Programs
C
- The GNU coding standards: http://www.gnu.org/prep/standards/
- Linux kernel coding style: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle
- Best practices for programming in C: http://www.ibm.com/developerworks/aix/library/au-hook_duttaC.html
- On C Library Implementation: http://rusty.ozlabs.org/?p=140
Python
Keep in mind:
Never do:
from module import *
Don't use mutable object as default parameter like this:
def func(l=[]): passUse it this way:
def func(l=None): if l is None: l = []When using string formatting operations like formatString % values you should always use a tuple if you're using non-mapping values. This is to avoid unexpected behavior when you think you're passing in a single value, but the value is unexpectedly a tuple, e.g.:
def foo(x): return "Hi %s\n" % xThe example shows you can pass in foo("foo") or foo(3) fine, but if you pass in foo((1,2)), it raises a TypeError. You should use this instead:
def foo(x): return "Hi %s\n" % (x,)For logging, should not use:
logging.debug('Hi %s' % msg)Use this instead:
logging.debug('Hi %s', msg)Avoid using '': it's ugly. For long lines, use this:
long_line = ('first part ' 'send part')Put license information in a separate 'LICENSE' file: easy to update and keep the source file cleaner.
Use lower case plus '_' for module file name.
Don't split a file at first: do it until needed.
A good example to split a module file: first keep everything in modulename.py, then split it into:
modulename |-- __init__.py |-- base.py `-- other.py
And import everything to __init__.py. So other code doesn't need to change.
Never do:
try: ... except: ...Instead, you can do:
try: ... except Exception: ...
Reference:
- PEP 8: Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
- Google Python style guide: http://code.google.com/p/soc/wiki/PythonStyleGuide
- Django coding style: http://docs.djangoproject.com/en/dev/internals/contributing/#coding-style
- pep8 - Python style guide checker: http://github.com/jcrocholl/pep8/
- PyChecker: http://pychecker.sourceforge.net/
- pylint: http://www.logilab.org/857
- Mercurial coding style: http://mercurial.selenic.com/wiki/CodingStyle
- Twisted Coding Standard: http://twistedmatrix.com/trac/browser/trunk/doc/core/development/policy/coding-standard.xhtml
HTML
- Composing Good HTML: http://www.ology.org/tilt/cgh/
- HTML Coding Guidelines: http://www.peachpit.com/articles/article.aspx?p=24011
Caml
- Caml programming guidelines: http://caml.inria.fr/resources/doc/guides/guidelines.en.html
Java
- Java Code Conventions: http://java.sun.com/docs/codeconv/
- Java Programming Style Guidelines: http://geosoft.no/development/javastyle.html
JavaScript
- http://stackoverflow.com/questions/211795/are-there-any-coding-standards-for-javascript
- Code Conventions for the JavaScript Programming Language: http://javascript.crockford.com/code.html
- Google JavaScript Style Guide: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
- http://code.google.com/p/soc/wiki/JavascriptStyleGuide
- http://c2.com/cgi/wiki?JavaScriptCodingStandard
- Drupal JavaScript coding standards: http://drupal.org/node/172169
