| [19bc74] | 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 | /**
|
|---|
| [f11c23] | 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
|
|---|
| [caece4] | 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.
|
|---|
| [f11c23] | 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
|
|---|
| [caece4] | 69 | * there. Just browse through the various test functions implemented in
|
|---|
| [f11c23] | 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
|
|---|
| [19bc74] | 104 | *
|
|---|
| [750cff] | 105 | * \li \ref faq
|
|---|
| 106 | * \li \ref constructs
|
|---|
| 107 | * \li \ref howto
|
|---|
| 108 | *
|
|---|
| 109 | *
|
|---|
| [caece4] | 110 | * \date 2014-03-10
|
|---|
| [19bc74] | 111 | *
|
|---|
| 112 | */
|
|---|
