Difference between revisions of "Janitorial tasks"

From Inkscape Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
== Improving headers for compilation speed ==
 
== Improving headers for compilation speed ==
 +
 
When a header file changes, any file that includes it is recompiled.  This becomes a problem when a given header file is included by other header files, as it leads to a vast header include tree, wherein a small change to a seemingly minor header file causes massive rebuilds of much of the codebase.   
 
When a header file changes, any file that includes it is recompiled.  This becomes a problem when a given header file is included by other header files, as it leads to a vast header include tree, wherein a small change to a seemingly minor header file causes massive rebuilds of much of the codebase.   
  
Fortunately for us, there are recognised techniques to mitigate this!  Here's what to do:
+
Fortunately for us, there are recognized techniques to mitigate this!  Here's what to do:
  
 
* Find a header that includes several other headers.  For example, the header "bar.h" might have a <code>class Bar</code> with a member of type <code>Foo*</code>, thus it includes "foo.h" to get the definition of that type.  You can prune this by using a 'forward declaration', whenever the <code>Foo</code> entity is not itself used, only pointers and/or references to it:
 
* Find a header that includes several other headers.  For example, the header "bar.h" might have a <code>class Bar</code> with a member of type <code>Foo*</code>, thus it includes "foo.h" to get the definition of that type.  You can prune this by using a 'forward declaration', whenever the <code>Foo</code> entity is not itself used, only pointers and/or references to it:
Line 14: Line 15:
 
  };
 
  };
  
Although there are still forward declaration headers in the source tree, those should be avoided in favor of individual forward declarations in .h files as needed.
+
Although there are still forward declaration headers in the source tree, those should be avoided in favor of individual forward declarations in .h files as needed. '''The exception is <tt>&lt;2geom/forward.h&gt;</tt>''', due to heavy use of templates in the 2Geom library.
  
 
(BPF) The [http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.11 C++ FAQ Sheet] explains how to code forward declarations (classes that both need to know about each other); To fully understand why, you should study the [http://www.gotw.ca/publications/mill04.htm Pimpl idiom].
 
(BPF) The [http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.11 C++ FAQ Sheet] explains how to code forward declarations (classes that both need to know about each other); To fully understand why, you should study the [http://www.gotw.ca/publications/mill04.htm Pimpl idiom].
  
 
== Source formatting ==
 
== Source formatting ==
 +
 +
=== Header ===
 +
 
* Source files should use four spaces as indentation and no tabs. Trailing whitespace should be removed.
 
* Source files should use four spaces as indentation and no tabs. Trailing whitespace should be removed.
* The comment at the top of each file should have the following format. First comes a Doxygen comment with a short description of the contents of the file. You should avoid meaningless descriptions such as "Inkscape::Preferences class implementation". Instead, if there is one class in the file, describe in a few words what this class is used for. If there are several, describe what they have in common. The author information is in a regular multiline comment so that it is omitted in the generated documentation. Author emails can be obfuscated, but should be real addresses.
+
* The comment at the top of each file should have the following format. The author information is in a regular multiline comment so that it is omitted in the generated documentation. Author emails can be obfuscated, but should be real addresses.
/** @file
+
** Using a Doxygen comments with <tt>@file</tt> at the top should no longer be the normal case. The comments need to document individual classes, subsystems, etc., and not be focused on file structure. Doxygen itself normally will address file-specific needs.
  * Logarithmic time travelling salesman solver
+
 
  *//*
+
/*
 
   * Authors:
 
   * Authors:
 
   *  J. God Hacker <ihatepizza@gurus.org>
 
   *  J. God Hacker <ihatepizza@gurus.org>
Line 31: Line 35:
 
   * Released under GNU GPL, read the file 'COPYING' for more information
 
   * Released under GNU GPL, read the file 'COPYING' for more information
 
   */
 
   */
 +
 +
Again, note that the comment does not start with "<tt>/**</tt>",. but only with "<tt>/*</tt>"
 +
 +
==== @file Command ====
 +
 +
* Modern C++ code should avoid global and static variables, functions, enums, etc. Legacy code migrated from C may still contain these, so will require the use of a <tt>@file</tt> command.
 +
* Note that the <tt>@file</tt> command will only be required for files that have non-class non-namespaced globals or statics. As our codebase moves to the more modern C++ practices, use of these will be reduced and removed.
 +
* Legacy files that contain a mix of functions probably warrant use of a <tt>@file</tt> command.
 +
* If feasible, moving statics to anonymous namespaces instead is preferable to adding a <tt>@file</tt> command.
 +
* Any documented entities in namespaces, of local classes, etc., will be processed even if a <tt>@file</tt> command is not present in the source file.
 +
 +
An example of a legacy source file using the <tt>@file</tt> command:
 +
 +
/**
 +
  * @file
 +
  * Logarithmic time traveling salesman solver.
 +
  */
 +
/*
 +
  * Authors:
 +
  *  J. God Hacker <ihatepizza@gurus.org>
 +
  *  Ellen Epic <epicwin at email dot com>
 +
  *
 +
  * Copyright (C) 2006-2008 Authors
 +
  * Released under GNU GPL, read the file 'COPYING' for more information
 +
  */
 +
 +
Note the following:
 +
* The opening doc comment is merely "<tt>/**</tt>" on a line by itself. Keeping the rest to subsequent lines aids legibility and revision tracking.
 +
* The <tt>@file</tt> command is on a line by itself, with nothing following. This is required to allow Doxygen to automatically extract the current filename.
 +
* The short description of the file contents (that follows starting on the line after <tt>@file</tt>) ends with a period. All short (aka "brief") descriptions should end with a period.
 +
* The end of the doc comment and the start of the normal comment (with authors) are on separate lines. Avoid collapsing them to "<tt>*//*</tt>"
 +
 +
=== Footer ===
 +
 
* Every source file should have the following Emacs local variable block and Vim modeline at the end:
 
* Every source file should have the following Emacs local variable block and Vim modeline at the end:
 +
 
  /*
 
  /*
 
   Local Variables:
 
   Local Variables:
Line 42: Line 81:
 
  */
 
  */
 
  // vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:fileencoding=utf-8:textwidth=99 :
 
  // vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:fileencoding=utf-8:textwidth=99 :
* Include style. In-tree includes should use quotes, while system headers should use angle brackets. An exception is 2Geom, which should use angle brackets, though it is local (we are preparing for it to become a standalone library one day). Includes in each group should be sorted alphabetically. The path should be relative to the <tt>src/</tt> directory. If there is a config.h include, it should go at the top. Here is an example:
+
 
 +
=== Include Statement Style ===
 +
 
 +
* Include style. In-tree includes should use quotes, while system headers should use angle brackets. An exception is 2Geom, which should use angle brackets, though it is local (we are preparing for it to become a standalone library one day). Includes in each group should be sorted alphabetically. The path should be relative to the <tt>src/</tt> directory. If there is a config.h include, it should go at the top and have an <tt>#ifdef</tt> guard. Here is an example:
 +
 
 
  #ifdef HAVE_CONFIG_H
 
  #ifdef HAVE_CONFIG_H
 
  # include "config.h"
 
  # include "config.h"
Line 56: Line 99:
 
  #include "sp-use.h"
 
  #include "sp-use.h"
 
  #include "xml/node.h"
 
  #include "xml/node.h"
* Order of the file. Each file should contain the following, in '''precisely''' that order:
+
 
** <tt>@file</tt> comment, which marks the file as containing documented entities. You can skip it for files that contain no documentation.
+
== Order of the file ==
** Copyright comment, as above.
+
 
** Include guard (only for header files)
+
* Each file should contain the following, in '''precisely''' that order:
 +
** When required for legacy needs, <tt>@file</tt> comment with a short description of the file's contents
 +
** Copyright comment with authors
 +
** Include guard (headers only)
 
** System includes
 
** System includes
 
** Local includes
 
** Local includes
** Forward declarations (note: although using an explicit forward declaration file used to be recommended, it no longer is. Using one had been found to be inefficient and error-prone. note on this note: lib2geom devs like 2geom/forward.h, so keep using it there! )
+
** Forward declarations
 
** Class declarations
 
** Class declarations
 
** Function declarations
 
** Function declarations
 
** Global variable declarations (note: global variables should be avoided)
 
** Global variable declarations (note: global variables should be avoided)
** End of include guard
+
** End of include guard (headers only)
** Emacs local variables block (see above)
+
** Emacs local variables block
** Vim modeline (see above)
+
** Vim modeline
  
 
== Documentation ==
 
== Documentation ==
  
* Many files begin with a Doxygen comment that doesn't contain the <tt>@file</tt> tag. The result is that the comment doesn't document the file, but the first entity declared in the file, usually the <tt>Inkscape</tt> namespace. Add a <tt>@file</tt> directive to them.
+
=== Document At Point of Declaration ===
 +
 
 +
* Items should normally be documented at their point of declaration, not definition.
 +
* For classes, namespaces, etc. this usually means to document in the .h file and not in the .cpp file.
 +
** The .h file represents the public API, or promise of functionality.
 +
** Doxygen comments have not been seen to be updated frequently enough to cause compilation issues from the .h files being touched. (Some developers had expressed concern that having comments in .h files would cause more frequent compilations)
 +
** It is easier for developers to read through a .h file for information on a class than going through an entire .cpp or set of .cpp files. Additionally, most modern development IDEs support ease of browsing, referencing, etc.
 +
* For local functions , declaring them at the beginning of the file they are local to and then implementing them later in the file allows a developer to quickly skim a summary of supported functionality. Pairing the doc comments with the initial declaration as opposed to the latter implementation helps legibility.
 +
** Of course, functions local to a single file should no longer be declared <tt>static</tt>, but instead be declared inside an anonymous namespace section in the file.
 +
 
 +
=== Make Comments Meaningful ===
 +
 
 
* Some documentation is useless, for example "constructor" or "destructor". Such comments mark the entity as documented, when in fact it's not. Remove them.
 
* Some documentation is useless, for example "constructor" or "destructor". Such comments mark the entity as documented, when in fact it's not. Remove them.
* When the <tt>@brief</tt> tag is skipped, Doxygen will use the first sentence (ending with a dot) as the brief description. An alternative is to put the description in a single-line comment. These two techniques can be used to reduce the number of directives. In the example below, all three functions will have the same documentation. The second case depends on the variable JAVADOC_AUTOBRIEF being set to true:
 
/// Something useful
 
/** This function does something very useful.
 
  * Here is its more detailed, longer description. */
 
void useful_function_one();
 
  
  /** Something useful.
+
=== @brief Command ===
 +
 
 +
* The <tt>@brief</tt> command comes from the more complex documentation format implemented by Trolltech before Doxygen was created. When the <tt>@brief</tt> command is skipped, Doxygen will use the first sentence (ending with a dot) as the brief description. An alternative is to put the description in a single-line comment. These two techniques can be used to reduce the number of Doxygen commands. In the example below, all three functions will have the same documentation. The first case depends on the variable JAVADOC_AUTOBRIEF being set to true, which is a main setting for Inkscape documentation:
 +
 
 +
  /**
 +
  * Something useful.
 
   * This function does something very useful.
 
   * This function does something very useful.
   * Here is its more detailed, longer description. */
+
   * Here is its more detailed, longer description.
 +
  */
 
  void useful_function_two();
 
  void useful_function_two();
  
  /** @brief Something useful.
+
/// Something useful
 +
  /**
 +
  * This function does something very useful.
 +
  * Here is its more detailed, longer description.
 +
  */
 +
void useful_function_one();
 +
 
 +
/**
 +
  * @brief Something useful.
 
   * This function does something very useful.
 
   * This function does something very useful.
   * Here is its more detailed, longer description. */
+
   * Here is its more detailed, longer description.
 +
  */
 
  void useful_function_three();
 
  void useful_function_three();
 +
 +
The use of <tt>@brief</tt> in Inkscape code comments is discouraged as redundant and overly verbose.
  
 
== Coding style ==
 
== Coding style ==
 +
 
* Replace C-style casts with the appropriate C++ casts. You can compile with <tt>-Wold-style-casts</tt> to find them easily.
 
* Replace C-style casts with the appropriate C++ casts. You can compile with <tt>-Wold-style-casts</tt> to find them easily.
 
** <tt>static_cast</tt> when the conversion is obvious, for example a floating point to integer type.
 
** <tt>static_cast</tt> when the conversion is obvious, for example a floating point to integer type.
 
** <tt>const_cast</tt> if the only difference between the types are <tt>const</tt> qualifiers.
 
** <tt>const_cast</tt> if the only difference between the types are <tt>const</tt> qualifiers.
 +
** <tt>dynamic_cast</tt> for downcasting to derived class type. Note that this is not needed to upcast to a parent type.
 
** <tt>reinterpret_cast</tt> if the conversion does not compile with static_cast, for example pointer to integer.
 
** <tt>reinterpret_cast</tt> if the conversion does not compile with static_cast, for example pointer to integer.
** <tt>dynamic_cast</tt> for downcasting to derived class type.
+
 
 +
Note that <tt>reinterpret_cast&lt;...&gt;(...)</tt> should be the cast of last resort.
  
 
== Elimination of old utest tests ==
 
== Elimination of old utest tests ==
 +
 
It should be double-checked that the old utest tests (also see [[TestSuite-blueprint]] are indeed all obsolete. If there happen to be any left that are not obsolete they should of course be converted to the CxxTest framework (if you don't feel up to it, ask me). Finally, the obsolete files should be removed from the repository and Makefiles, making sure that nothing breaks in the process.
 
It should be double-checked that the old utest tests (also see [[TestSuite-blueprint]] are indeed all obsolete. If there happen to be any left that are not obsolete they should of course be converted to the CxxTest framework (if you don't feel up to it, ask me). Finally, the obsolete files should be removed from the repository and Makefiles, making sure that nothing breaks in the process.
  
 
[[Category:Developer Documentation]]
 
[[Category:Developer Documentation]]
 
[[Category:Help Wanted]]
 
[[Category:Help Wanted]]

Latest revision as of 10:05, 6 January 2012

Before embarking on any of those tasks, be sure to contact the developers on the mailing list.

Improving headers for compilation speed

When a header file changes, any file that includes it is recompiled. This becomes a problem when a given header file is included by other header files, as it leads to a vast header include tree, wherein a small change to a seemingly minor header file causes massive rebuilds of much of the codebase.

Fortunately for us, there are recognized techniques to mitigate this! Here's what to do:

  • Find a header that includes several other headers. For example, the header "bar.h" might have a class Bar with a member of type Foo*, thus it includes "foo.h" to get the definition of that type. You can prune this by using a 'forward declaration', whenever the Foo entity is not itself used, only pointers and/or references to it:
//#include "foo.h"  /* <-- kill the header include! */
class Foo;          /* <-- replace with a forward declaration */
class Bar {
    Foo* _foo;
};

Although there are still forward declaration headers in the source tree, those should be avoided in favor of individual forward declarations in .h files as needed. The exception is <2geom/forward.h>, due to heavy use of templates in the 2Geom library.

(BPF) The C++ FAQ Sheet explains how to code forward declarations (classes that both need to know about each other); To fully understand why, you should study the Pimpl idiom.

Source formatting

Header

  • Source files should use four spaces as indentation and no tabs. Trailing whitespace should be removed.
  • The comment at the top of each file should have the following format. The author information is in a regular multiline comment so that it is omitted in the generated documentation. Author emails can be obfuscated, but should be real addresses.
    • Using a Doxygen comments with @file at the top should no longer be the normal case. The comments need to document individual classes, subsystems, etc., and not be focused on file structure. Doxygen itself normally will address file-specific needs.
/*
 * Authors:
 *   J. God Hacker <ihatepizza@gurus.org>
 *   Ellen Epic <epicwin at email dot com>
 *
 * Copyright (C) 2006-2008 Authors
 * Released under GNU GPL, read the file 'COPYING' for more information
 */

Again, note that the comment does not start with "/**",. but only with "/*"

@file Command

  • Modern C++ code should avoid global and static variables, functions, enums, etc. Legacy code migrated from C may still contain these, so will require the use of a @file command.
  • Note that the @file command will only be required for files that have non-class non-namespaced globals or statics. As our codebase moves to the more modern C++ practices, use of these will be reduced and removed.
  • Legacy files that contain a mix of functions probably warrant use of a @file command.
  • If feasible, moving statics to anonymous namespaces instead is preferable to adding a @file command.
  • Any documented entities in namespaces, of local classes, etc., will be processed even if a @file command is not present in the source file.

An example of a legacy source file using the @file command:

/**
 * @file
 * Logarithmic time traveling salesman solver.
 */
/*
 * Authors:
 *   J. God Hacker <ihatepizza@gurus.org>
 *   Ellen Epic <epicwin at email dot com>
 *
 * Copyright (C) 2006-2008 Authors
 * Released under GNU GPL, read the file 'COPYING' for more information
 */

Note the following:

  • The opening doc comment is merely "/**" on a line by itself. Keeping the rest to subsequent lines aids legibility and revision tracking.
  • The @file command is on a line by itself, with nothing following. This is required to allow Doxygen to automatically extract the current filename.
  • The short description of the file contents (that follows starting on the line after @file) ends with a period. All short (aka "brief") descriptions should end with a period.
  • The end of the doc comment and the start of the normal comment (with authors) are on separate lines. Avoid collapsing them to "*//*"

Footer

  • Every source file should have the following Emacs local variable block and Vim modeline at the end:
/*
  Local Variables:
  mode:c++
  c-file-style:"stroustrup"
  c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
  indent-tabs-mode:nil
  fill-column:99
  End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:fileencoding=utf-8:textwidth=99 :

Include Statement Style

  • Include style. In-tree includes should use quotes, while system headers should use angle brackets. An exception is 2Geom, which should use angle brackets, though it is local (we are preparing for it to become a standalone library one day). Includes in each group should be sorted alphabetically. The path should be relative to the src/ directory. If there is a config.h include, it should go at the top and have an #ifdef guard. Here is an example:
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif

#include <cairo.h>
#include <cstdio>
#include <glib.h>
#include <math.h>

#include "display/cairo-utils.h"
#include "document.h"
#include "sp-use.h"
#include "xml/node.h"

Order of the file

  • Each file should contain the following, in precisely that order:
    • When required for legacy needs, @file comment with a short description of the file's contents
    • Copyright comment with authors
    • Include guard (headers only)
    • System includes
    • Local includes
    • Forward declarations
    • Class declarations
    • Function declarations
    • Global variable declarations (note: global variables should be avoided)
    • End of include guard (headers only)
    • Emacs local variables block
    • Vim modeline

Documentation

Document At Point of Declaration

  • Items should normally be documented at their point of declaration, not definition.
  • For classes, namespaces, etc. this usually means to document in the .h file and not in the .cpp file.
    • The .h file represents the public API, or promise of functionality.
    • Doxygen comments have not been seen to be updated frequently enough to cause compilation issues from the .h files being touched. (Some developers had expressed concern that having comments in .h files would cause more frequent compilations)
    • It is easier for developers to read through a .h file for information on a class than going through an entire .cpp or set of .cpp files. Additionally, most modern development IDEs support ease of browsing, referencing, etc.
  • For local functions , declaring them at the beginning of the file they are local to and then implementing them later in the file allows a developer to quickly skim a summary of supported functionality. Pairing the doc comments with the initial declaration as opposed to the latter implementation helps legibility.
    • Of course, functions local to a single file should no longer be declared static, but instead be declared inside an anonymous namespace section in the file.

Make Comments Meaningful

  • Some documentation is useless, for example "constructor" or "destructor". Such comments mark the entity as documented, when in fact it's not. Remove them.

@brief Command

  • The @brief command comes from the more complex documentation format implemented by Trolltech before Doxygen was created. When the @brief command is skipped, Doxygen will use the first sentence (ending with a dot) as the brief description. An alternative is to put the description in a single-line comment. These two techniques can be used to reduce the number of Doxygen commands. In the example below, all three functions will have the same documentation. The first case depends on the variable JAVADOC_AUTOBRIEF being set to true, which is a main setting for Inkscape documentation:
/**
 * Something useful.
 * This function does something very useful.
 * Here is its more detailed, longer description.
 */
void useful_function_two();
/// Something useful
/**
 * This function does something very useful.
 * Here is its more detailed, longer description.
 */
void useful_function_one();
/**
 * @brief Something useful.
 * This function does something very useful.
 * Here is its more detailed, longer description.
 */
void useful_function_three();

The use of @brief in Inkscape code comments is discouraged as redundant and overly verbose.

Coding style

  • Replace C-style casts with the appropriate C++ casts. You can compile with -Wold-style-casts to find them easily.
    • static_cast when the conversion is obvious, for example a floating point to integer type.
    • const_cast if the only difference between the types are const qualifiers.
    • dynamic_cast for downcasting to derived class type. Note that this is not needed to upcast to a parent type.
    • reinterpret_cast if the conversion does not compile with static_cast, for example pointer to integer.

Note that reinterpret_cast<...>(...) should be the cast of last resort.

Elimination of old utest tests

It should be double-checked that the old utest tests (also see TestSuite-blueprint are indeed all obsolete. If there happen to be any left that are not obsolete they should of course be converted to the CxxTest framework (if you don't feel up to it, ask me). Finally, the obsolete files should be removed from the repository and Makefiles, making sure that nothing breaks in the process.