| 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 |  */
 | 
|---|