source: src/documentation/code.dox

Candidate_v1.6.1
Last change on this file was caece4, checked in by Frederik Heber <heber@…>, 11 years ago

Enhanced documentation significantly.

  • went through all of the constructs and updated each.
  • enhanced documentation ofr Fragmentation::FragmentMolecule().
  • Property mode set to 100644
File size: 4.8 KB
Line 
1/*
2 * Project: MoleCuilder
3 * Description: creates and alters molecular systems
4 * Copyright (C) 2010 University of Bonn. All rights reserved.
5 * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
6 */
7
8/**
9 * \file code.dox
10 *
11 * Created on: Oct 28, 2011
12 * Author: heber
13 */
14
15/**
16 * \page code How to use and extend the code
17 *
18 * \section code-introduction How to understand the code
19 *
20 * \subsection code-introduction-whats-there What's there already ...
21 *
22 * Generally, you will begin by having to add a certain Action to the code.
23 * Refer to the \ref constructs and (at the very least briefly) go through
24 * all the stuff that is already there. This should give you an idea of what
25 * you do not have to re-invent!
26 *
27 * As soon as you have decided upon all the little things required for your
28 * Action, e.g. you need a LinkedCell construct because of nearest neighbor,
29 * additionally you need access to BondGraph because you need bond distance
30 * information, you want to know how to access and use each of these.
31 *
32 * \subsection code-introduction-whats-not-there What's not there ...
33 *
34 * Not everything is always documented, not everything is always up-to-date.
35 * Search the code or try to look at Actions that are similar to what you
36 * intent. Try to understand what they do, how they achieve it and whever your
37 * ideas really can't be realized with the current capabilities of the code
38 * already.
39 *
40 * If not, it gets more complicated because if one extends the code, one can
41 * proceed in a straight-forward and soon-to-reach-the-goal way or one can
42 * try to realize if one's not generalizing a concept already present and
43 * implement this generalization (and also bring what's already there up to
44 * speed with this new implementation). Of course, before this "refactoring"
45 * (http://en.wikipedia.org/wiki/Code_refactoring) one should have tests in
46 * place that safeguard that the old functionality remains the same, see
47 * \ref tests. From this generalization your concept should then be easier
48 * to implement.
49 *
50 * Last but not least, see \ref future for what some of the areas are where
51 * the code needs extension or refactorization. Maybe somethings close to what
52 * you want and you could do it along the way, at the same time getting to
53 * know the code better?
54 *
55 * \section code-howto-use How to use the code
56 *
57 * There are two things that should make it easy for you to get to know the
58 * constructs, i.e. classes, required for your Action besides the documentation
59 * and serve as tiny examples on how to use them:
60 * - unit tests
61 * - regression tests
62 *
63 * \subsection code-howto-use-unit-tests Unit tests
64 *
65 * Unit tests give you an idea how to use a specific constructs, e.g. they
66 * tell you where to get it (simply \code new LinkedCell \endcode, or rather
67 * \code World::getInstance().getBondGraph() \endcode, because it's a unique
68 * instance) and how to use them because that's exactly what's being tested
69 * there. Just browse through the various test functions implemented in
70 * each of the unit tests or rather the unit tests to the constructs you need.
71 *
72 * \subsection code-howto-use-regression-tests Regression tests
73 *
74 * Regression tests (\ref tests-regressiontests) give you an idea how your
75 * Action eventually can be called (from the command line), what to put in your
76 * \b .def file and how it ends up being the option you have to give.
77 *
78 * \attention Never forget that you are supposed to add a regression test for
79 * your new Action as well, either right now (http://en.wikipedia.org/wiki/Test-driven_development)
80 * or at the very latest once its finished.
81 *
82 * \subsection code-howto-use-last Last but not least
83 *
84 * Search the code with the desired construct as keyword to find out places
85 * where it is internally used, see how it is done there and do the same
86 * in your own Action.
87 *
88 * \section code-introduction-howto-extend How to extend the code
89 *
90 * Once you're certain your requirements are not met, new classes have to be
91 * added. Do some careful thinking whether you add something altogether new or
92 * whether it's already present in some simpler or slightly other form. In the
93 * latter case, try to generalize what's present and build from there. E.g.
94 * FormatParserParameters have been generalized from a simpler implementation
95 * that was just used for the parameters for MpqcParser (know FormatParser<mpqc>
96 * which has been refactored as well). Don't always go all the way, but extend
97 * and generalize when it makes sense, especially when the code is much easier
98 * to use afterwards or just much more powerful (with immediate consequences).
99 *
100 * Again, refer to \ref future to know what's already on the schedule, i. e.
101 * what's already marked for extension or refactoring.
102 *
103 * \section code-reference Further readings
104 *
105 * \li \ref faq
106 * \li \ref constructs
107 * \li \ref howto
108 *
109 *
110 * \date 2014-03-10
111 *
112 */
Note: See TracBrowser for help on using the repository browser.