Difference between revisions of "Coding Style Guidelines"
(Created page with " ==Editor== ===Line Wrapping=== ===Indentation=== ==Revision Control== All code should exist in a revision control system. It can be SVN or Git or whatever your choice. I...") |
|||
Line 1: | Line 1: | ||
− | + | In general, if you have a legacy project, you should follow the same style guidelines as are already in that project. Unless you want to reformat and fix the ENTIRE project. Consult with me before doing this, but it is probably a waste of time. | |
==Editor== | ==Editor== | ||
+ | |||
+ | You should be using emacs or vim. Do not use anything else. | ||
+ | |||
+ | Learn to use your editor well by completing online tutorials. Starting learning a new "tip" every week. If it is very useful, share it with the group via the email list! | ||
===Line Wrapping=== | ===Line Wrapping=== | ||
===Indentation=== | ===Indentation=== | ||
+ | |||
==Revision Control== | ==Revision Control== |
Revision as of 21:29, 25 June 2013
In general, if you have a legacy project, you should follow the same style guidelines as are already in that project. Unless you want to reformat and fix the ENTIRE project. Consult with me before doing this, but it is probably a waste of time.
Editor
You should be using emacs or vim. Do not use anything else.
Learn to use your editor well by completing online tutorials. Starting learning a new "tip" every week. If it is very useful, share it with the group via the email list!
Line Wrapping
Indentation
Revision Control
All code should exist in a revision control system. It can be SVN or Git or whatever your choice. I recommend the group repository.
You should not commit any temporary files into a repository. If it is a temporary or generated file, it will change automatically every time you compile. This then causes unnecessary differences in the repository and creates bloat.
Do not check in non-working code. Before you check in, you should verify that any unit tests pass and that all new files are added. Ommitting a file will break the code for everyone else! Use svn status to check if you have any files not added or are still locally modified.
Clean Code
Chapter 2 Self_explain, long enough to express, as short as possible Noun for class, verb for function. Easy to search, pronounce is bounus
Chapter 3 Small No more than 3 paramters, this is because do one thing at a time and clear level
Chapter 4 Best comment is no comment
Chapter 5 Vertical one: downwards rule. High level to low. Stay close if conceptual affinity Horizontal one: enforced by python.
Chapter 6 Object expose behavior Data(class) expose obviously data similar to the idea of Separate the data path and control path
Chapter 7 concept of exception do not exist in python. However, the code should provide helpful information than just producing error message. Null information should not be produced or passed, error class is better.
Bin Wu its called checked exception in the book(Page 106, Use Unchecked Exceptions ,Paragraph 2). I am still a little bit confused about that chapter. Does assert do the same job?