Module coding_style
[hide private]
[frames] | no frames]

Source Code for Module coding_style

  1  #!/usr/bin/env python 
  2  # encoding: utf-8 
  3   
  4  # Schlachtfeld - Großkämpfe im EWS System 
  5  #   http://rpg-tools-1d6.sf.net 
  6  # Copyright © 2007 - 2007 Achim Zien 
  7   
  8  # This program is free software; you can redistribute it and/or modify 
  9  # it under the terms of the GNU General Public License as published by 
 10  # the Free Software Foundation; either version 2 of the License, or 
 11  # (at your option) any later version. 
 12   
 13  # This program is distributed in the hope that it will be useful, 
 14  # but WITHOUT ANY WARRANTY; without even the implied warranty of 
 15  # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
 16  # GNU General Public License for more details. 
 17   
 18  # You should have received a copy of the GNU General Public License 
 19  # along with this program; if not, write to the Free Software 
 20  # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, 
 21  # MA 02110-1301 USA 
 22   
 23  # This code-file is an example for coding style to use.  
 24   
 25  """The coding style for the Schlachtfeld project. A short overview of the functions and classes in a file should the first line of its docstring,  
 26   
 27  It should be tested with epydoc version 3.0 or higher.  
 28   
 29  Files which contain at least one class should be structured around imports, constants, classes, functions and self-test. Please look into the coding_style.py file to see an example and descriptions of each part of the file.  
 30   
 31  The files should rather contain too many comments than too few.  
 32   
 33  This coding style is in RFC mode: Request for comment. Please see it as a beta at best and type comments directly into this file, beginning with a "> " sign.  
 34   
 35  Useage:  
 36  In the explanation texts the file should contain general usage instructions like ways to call the class and examples.  
 37   
 38  To get the coding style, have a look at the codefile, or let it be processed by epydoc. 
 39   
 40  Variables and comments should be in english.  
 41  Classes should be written with leading Capital.  
 42   
 43  Functions in all lowercase, words seperated by underscores.  
 44   
 45  Plans and Ideas:  
 46  Also the first docstring of a file should contain plans and ideas, so that they are all gathered at one central place and can be read out by epydoc.  
 47   
 48  This also eases the transition between version management systems (in future) and since epydoc produces nicely laid out websites, it still stays accessible.  
 49   
 50  Plans should be included once they are somewhat fixed, ideas should contain a link to a discussion page.  
 51   
 52  Once an idea got discussed, its solution should be included as a plan.  
 53   
 54  IDEA:  
 55  Maybe plans and ideas could be put into functions which serve only as anchors for docstrings. Maybe they would justify adding a first section in sourcefiles namesn PLANS AND IDEAS. Epydoc will show them as functions, then.  
 56   
 57  To differenciate plans and ideas from other functions, they could all start with a common char, for example x like in:  
 58   
 59  x_plan_morale_implementation 
 60   
 61  this way they would also get sorted down in lists and wouldn't interfer with reading otehr functins.  
 62   
 63  """ 
 64   
 65  #### IMPORTS #### 
 66   
 67  # Any imports should go into this section.  
 68   
 69  #### IMPORTS #### 
 70   
 71   
 72  #### CONSTANTS #### 
 73   
 74  # And global constants need to go here.  
 75   
 76  #### CONSTANTS #### 
 77   
 78   
 79  #### CLASSES #### 
 80   
 81  # All classes of teh files.  
 82   
83 -class CodingStyle():
84 """A docstring describing the class should be included for every class. 85 86 Details for plans with the class and information for adapting it should also go into the docstring. 87 88 A docstring should be seperated from the following code by at least one empty line to lessen confusion.""" 89
90 - def __init__(self, style="style"):
91 """Every function needs a docstring, too. 92 93 Additional lines should contain special cases and any quirks which might not behave exactly as expected.""" 94 95 #: The coding style. Every variable needs a description in epydoc format. 96 self.style = style 97
98 - def __repr__(self):
99 """Information about the class which is intended to be seen by a user of the program, not by a developer. Print it, if it's intended for command line useage, else return it as string. """ 100 return "coding style. Please see the code-file." 101 102 #### CLASSES #### 103 104 105 #### FUNCTIONS #### 106 107 # This section contains all kind of funtions which aren't encapsulated into classes. 108 109 #### FUNCTIONS #### 110 111 112 #### SELF-TEST #### 113 114 if __name__ == "__main__": 115 # test relevant parts of the file. 116 #: An example call of the CodingStyle class. 117 style = CodingStyle() 118 # print the coding style. 119 print style 120 121 #### SELF-TEST #### 122