README.hacking

# -*- Outline -*-
#
# Copyright 2004,2007,2008,2009,2018 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
#

* Getting started with GNU Radio development.

If you're new to developing software with GNU Radio, please refer to

https://tutorials.gnuradio.org/

Heaving read this will be very helpful when you're diving into the GNU Radio
source code tree.

* About this document

Random notes on coding conventions, some explanations about why things
aren't done differently, etc, etc,


* Boost 1.35

Boost 1.35 and later is fairly common in modern distributions.
If it isn't available for your system, please refer to
README.building-boost for instructions

* C++ and Python

GNU Radio is a hybrid system.  Some parts of the system are built in C++ and
some of it in Python.  In general, prefer Python to C++ for its simplicity; for
performance-critical and system-related functionality use C++. Signal
processing primitives are still built in C++ for performance; the
Vector-Optimized Library of Kernels (VOLK) is directly accessible from C++.


* C++ namespaces

GNU Radio is organized in modules. For example, the blocks of the gr-digital
module reside in the namespace gr::digital. Out-Of-Tree modules follow the
same convention, but should take care not to clash with the official modules.

* Naming conventions

Death to CamelCaseNames!  We've returned to a kinder, gentler era.
We're now using the "STL style" naming convention with a couple of
modifications. Refer to the classes in the official source tree for
examples.

With the exception of macros and other constant values, all
identifiers shall be lower case with words_separated_like_this.

Macros and constant values (e.g., enumerated values,
static const int FOO = 23) shall be in UPPER_CASE.


** Class data members (instance variables)

All class data members shall begin with d_<foo>.

The big benefit is when you're staring at a block of code it's obvious
which of the things being assigned to persist outside of the block.
This also keeps you from having to be creative with parameter names
for methods and constructors.  You just use the same name as the
instance variable, without the d_.

class wonderfulness {
  std::string	d_name;
  double	d_wonderfulness_factor;

public:
  wonderfulness (std::string name, double wonderfulness_factor)
    : d_name (name), d_wonderfulness_factor (wonderfulness_factor)
  {
    ...
  }
  ...
};


** Class static data members (class variables)

All class static data members shall begin with s_<foo>.


** File names

Each significant class shall be contained in its own file.

* Storage management

Strongly consider using the boost smart pointer templates, scoped_ptr
and shared_ptr.  scoped_ptr should be used for locals that contain
pointers to objects that we need to delete when we exit the current
scope.  shared_ptr implements transparent reference counting and is a
major win.  You never have to worry about calling delete.  The right
thing happens.

See http://www.boost.org/libs/smart_ptr/smart_ptr.htm


* Unit tests

Unit tests are a useful tool for development -- they  are less of a tool
to prove others that you can write code that works like you defined it but help
you and later maintainers identify corner cases, regressions and other malfunctions
of code.

GNU Radio has integrated versatile, easy to use testing facilities. Please refer to

https://wiki.gnuradio.org/index.php/Coding_guide_impl#Unit-testing


* Standard command line options

When writing programs that are executable from the command line,
please follow these guidelines for command line argument names (short
and long) and types of the arguments.  We list them below using the
Python argparse syntax.  In general, the default value should be coded
into the help string using the "... [default=%(default)r]" syntax.

** Mandatory options by gr::block

When designing flow graphs with the GNU Radio Companion, appropriate
option parsing will automatically be set up for you.

*** Audio source

Any program using an audio source shall include:

  add_argument("-I", "--audio-input", default="",
             help="pcm input device name.  E.g., hw:0,0 or /dev/dsp")

The default must be "".  This allows an audio module-dependent default
to be specified in the user preferences file.


*** Audio sink

  add_argument("-O", "--audio-output", default="",
             help="pcm output device name.  E.g., hw:0,0 or /dev/dsp")

The default must be "".  This allows an audio module-dependent default
to be specified in the user preferences file.


** Standard options names by parameter

Whenever you want an integer, use the "intx" type.  This allows the
user to input decimal, hex or octal numbers.  E.g., 10, 012, 0xa.

Whenever you want a float, use the "eng_float" type.  This allows the
user to input numbers with SI suffixes.  E.g, 10000, 10k, 10M, 10m, 92.1M

If your program allows the user to specify values for any of the
following parameters, please use these options to specify them:


To specify a frequency (typically an RF center frequency) use:

  add_argument("-f", "--freq", type=eng_float, default=<your-default-here>,
             help="set frequency to FREQ [default=%(default)r]")


To specify a decimation factor use:

  add_argument("-d", "--decim", type=intx, default=<your-default-here>,
             help="set decimation rate to DECIM [default=%(default)r]")


To specify an interpolation factor use:

  add_argument("-i", "--interp", type=intx, default=<your-default-here>,
             help="set interpolation rate to INTERP [default=%(default)r]")


To specify a gain setting use:

  add_argument("-g", "--gain", type=eng_float, default=<your-default-here>,
             help="set gain in dB [default=%(default)r]")


If your application specifies both a tx and an rx gain, use:

  add_argument("--rx-gain", type=eng_float, default=<your-default-here>,
            help="set receive gain in dB [default=%(default)r]")

  add_argument("--tx-gain", type=eng_float, default=<your-default-here>,
             help="set transmit gain in dB [default=%(default)r]")


To specify the number of channels of something use:

  add_argument("-n", "--nchannels", type=intx, default=1,
             help="specify number of channels [default=%(default)r]")


To specify an output filename use:

  add_argument("-o", "--output-filename", default=<your-default-here>,
             help="specify output-filename [default=%(default)r]")


To specify a rate use:

  add_argument("-r", "--bit-rate", type=eng_float, default=<your-default-here>,
             help="specify bit-rate [default=%(default)r]")
     or

  add_argument("-r", "--sample-rate", type=eng_float, default=<your-default-here>,
             help="specify sample-rate [default=%(default)r]")


If your application has a verbose option, use:

  add_argument('-v', '--verbose', action="store_true",
             help="verbose output")


If your application allows the user to specify the "fast USB" options, use:

  add_argument("--fusb-block-size", type=intx, default=0,
             help="specify fast USB block size [default=%(default)r]")

  add_argument("--fusb-nblocks", type=intx, default=0,
             help="specify number of fast USB blocks [default=%(default)r]")