Skip to content

Coding Standards

jimim22 edited this page Feb 13, 2013 · 7 revisions

With more us of us working on python we need to talk about some coding standards, etc We do not need to do things the way ksl has always done them, but we do need to agree that this is what we will do. Issues include documentation of code, how do we add and then remove test code, how long do we keep old code around, etc. It is a good time to do this if we are also going to use something like github.

Note - ksl I don't think we have the time to enforce a coding standard on everything we have done in the past. I am thinking about something going foward, and something which we can push too as we update code.

Documentation

Generally, python has a header file in front of each routine. What is contained there is somewhat variable. Knox tended to try to write a description of the code that and its general purpose. He usually though not always added major changes in a history file. There is a lot of variation thought both in what Nick and Knox have done about this, and some things are in the code itself.

Knox and Nick have tended to comment old code out, with the words old to leave remnant code around. It's possible that github will get rid of this

Style

Knox used a the beautifier on linux to put the code into a common appearance. I don't believe Nick does this, and Knox has not done it recently. We probably should do this again, but we need a "beautifier" routine that works on all systems and produces the same results. Note that different editors have differnt conventions, so we need to do something.

An issue is that when we beautify the routines, github etc will find all of these style changes different.

Note - the unix beautifier, or the one I have used in the past, is called indent. One has to be careful about the defaults on different systems, because they are different. It's probable, that with the right switches they can be made the same

Additional commands for testing

Nick (and Knox) often add lines for testing. These lines really need to come out of the program at some point, but the question is how/when to get them out. Nick has a tendency to add extra printout statements that include his initials. This seems like a good idea - since we can tell at least who put a piece of code in.