git.gag.com Git - debian/gnuradio/blob - README.hacking

   1 # -*- Outline -*-
   2 #
   3 # Copyright 2004 Free Software Foundation, Inc.
   4 #
   5 # This file is part of GNU Radio
   6 #
   7 # GNU Radio is free software; you can redistribute it and/or modify
   8 # it under the terms of the GNU General Public License as published by
   9 # the Free Software Foundation; either version 2, or (at your option)
  10 # any later version.
  11 #
  12 # GNU Radio is distributed in the hope that it will be useful,
  13 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  14 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  15 # GNU General Public License for more details.
  16 #
  17 # You should have received a copy of the GNU General Public License
  18 # along with GNU Radio; see the file COPYING.  If not, write to
  19 # the Free Software Foundation, Inc., 51 Franklin Street,
  20 # Boston, MA 02110-1301, USA.
  21 #
  22
  23
  24 Random notes on coding conventions, some explanations about why things
  25 aren't done differently, etc, etc,
  26
  27
  28 * C++ and Python
  29
  30 GNU Radio is now a hybrid system.  Some parts of the system are built
  31 in C++ and some of it in Python.  In general, prefer Python to C++.
  32 Signal processing primitives are still built in C++ for performance.
  33
  34 It is no longer possible to build user applications entirely in C++.
  35 Essential parts of the runtime system have been moved into Python.
  36
  37
  38 * C++ namespaces
  39
  40 In the cleanup process, I considered putting everything in the
  41 gnuradio namespace and dropping the Gr|gr prefix.  In fact, I think
  42 it's probably the right idea, but when I tested it out, I ran into
  43 problems with SWIG's handling of namespaces.  Bottom line, SWIG
  44 (1.3.21) got confused and generated bad code when I started playing
  45 around with namespaces in a not particularly convoluted way.  I saw
  46 problems using the boost::shared_ptr template in combination with
  47 classes defined in the gnuradio namespace.  It wasn't pretty...
  48
  49
  50 * Naming conventions
  51
  52 Death to CamelCaseNames!  We've returned to a kinder, gentler era.
  53 We're now using the "STL style" naming convention with a couple of
  54 modifications since we're not using namespaces.
  55
  56 With the exception of macros and other constant values, all
  57 identifiers shall be lower case with words_separated_like_this.
  58
  59 Macros and constant values (e.g., enumerated values,
  60 static const int FOO = 23) shall be in UPPER_CASE.
  61
  62
  63 ** Global names
  64
  65 All globally visible names (types, functions, variables, consts, etc)
  66 shall begin with a "package prefix", followed by an '_'.  The bulk of
  67 the code in GNU Radio logically belongs to the "gr" package, hence
  68 names look like gr_open_file (...).
  69
  70 Large coherent bodies of code may use other package prefixes, but
  71 let's try to keep them to a well thought out list.  See the list
  72 below.
  73
  74 *** Package prefixes
  75
  76 These are the current package prefixes:
  77
  78     gr_         Almost everything
  79
  80     gri_        Implementation primitives.  Sometimes we
  81                 have both a gr_<foo> and a gri_<foo>.  In that case,
  82                 gr_<foo> would be derived from gr_block and gri_<foo>
  83                 would be the low level guts of the function.
  84
  85     atsc_       Code related to the Advanced Television
  86                 Standards Committee HDTV implementation
  87
  88     usrp_       Universal Software Radio Peripheral
  89
  90     qa_         Quality Assurance.  Test code.
  91
  92
  93 ** Class data members (instance variables)
  94
  95 All class data members shall begin with d_<foo>.
  96
  97 The big win is when you're staring at a block of code it's obvious
  98 which of the things being assigned to persist outside of the block.
  99 This also keeps you from having to be creative with parameter names
 100 for methods and constructors.  You just use the same name as the
 101 instance variable, without the d_.
 102
 103 class gr_wonderfulness {
 104   std::string   d_name;
 105   double        d_wonderfulness_factor;
 106
 107 public:
 108   gr_wonderfulness (std::string name, double wonderfulness_factor)
 109     : d_name (name), d_wonderfulness_factor (wonderfulness_factor)
 110   {
 111     ...
 112   }
 113   ...
 114 };
 115
 116
 117 ** Class static data members (class variables)
 118
 119 All class static data members shall begin with s_<foo>.
 120
 121
 122 ** File names
 123
 124 Each significant class shall be contained in it's own file.  The
 125 declaration of class gr_foo shall be in gr_foo.h, the definition in
 126 gr_foo.cc.
 127
 128
 129
 130 * Storage management
 131
 132 Strongly consider using the boost smart pointer templates, scoped_ptr
 133 and shared_ptr.  scoped_ptr should be used for locals that contain
 134 pointers to objects that we need to delete when we exit the current
 135 scope.  shared_ptr implements transparent reference counting and is a
 136 major win.  You never have to worry about calling delete.  The right
 137 thing happens.
 138
 139 See http://www.boost.org/libs/smart_ptr/smart_ptr.htm
 140
 141
 142 * Unit tests
 143
 144 Build unit tests for everything non-trivial and run them after every
 145 change.  Check out Extreme Programming:
 146 http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
 147
 148 Unit tests should also be written for all examples.  This should kill
 149 off the bit rot we've been plagued with.
 150
 151 ** C++ unit tests
 152
 153 For C++ we're using the cppunit framework.  cppunit has its bad
 154 smells, but it's mostly workable.  http://cppunit.sf.net
 155
 156 Currently each directory <dirname> contains files qa_<dirname>.{h,cc}
 157 that bring together all the qa_<foo> test suites in the directory.
 158 We ought to be able to automate this without too much trouble.
 159
 160 The directory gnuradio-core/src/tests contains programs that run
 161 the tests.  test_all runs all of the registered C++ unit tests.
 162
 163 As far as I can tell, the cppunit TestFactoryRegistry maybe able to be
 164 tricked into doing what we want.  As is, I don't think it's enough by
 165 itself, since there's nothing dragging the qa* files out of the
 166 library and into the program.   I haven't tested out this idea.
 167
 168 ** Python unit tests
 169
 170 We use the standard unittest package for unit testing of Python code.
 171
 172
 173 * Subversion line ending styles
 174
 175 All text files in the tree should have the subversion property
 176 'svn:eol-style' set to 'native', with the following exceptions:
 177
 178 config/*.m4
 179 configure.ac
 180 gr-howto-write-a-block/config/*.m4
 181 gr-howto-write-a-block/configure.ac
 182
 183 The easiest way to ensure this is to add or edit the following lines in
 184 your svn client configuration file (~/.subversion/config):
 185
 186 enable-auto-props=yes
 187
 188 [auto-props]
 189 *.c = svn:eol-style=native
 190 *.cc = svn:eol-style=native
 191 *.i = svn:eol-style=native
 192 *.h = svn:eol-style=native
 193 *.am = svn:eol-style=native
 194 *.py = svn:eol-style=native
 195 *.ac = svn:eol-style=LF
 196 *.m4 = svn:eol-style=LF
 197
 198 * Misc tips
 199
 200 ccache, a compiler cache, can really speed up your builds.
 201 See http://ccache.samba.org/
 202
 203 Be sure to create links for gcc and g++