The libRosetta source code follows a set of conventions designed to make it easier to find
things and to understand the source. An example of an interface class definition is shown at right and notes on the source code follow.
Naming
- Class names are generally in CamelCase (mixed case) and data member and functions in lower_case. For compatibility with STL naming, where some types such as value_type are lower case, some libRosetta classes provide both sets of typedef names.
- Private data members have names ending with '_', such as key_, angle_, or position_. The accessor functions are named without the '_', such as key(), angle(), or position().
- The interface and other primary directories correspond to the namespace organization.
- Typedef names are used to provide class-local names for types to insulate the classes and code that uses them from changes to the choice of implementing class.
- Scalar floating point types have been given typedef names to help document the source and to allow libRosetta to be easily built with different floating point precisions for all or some of the primary types. This also provides some future-proofing: we can easily change some of those scalars to classes if the need arises.
Class Organization
Class definitions include some subset of the following categories in this order:
- Types
- Friends
- Creation: Constructors, destructors, and related creational member functions
- Assignments
- Conversion functions
- Methods: Member functions that do more than simple property getters or setters
- Properties: Property accessor and assignment member functions (properties can include computed state values as well as data members)
- Indexers: Indexing/subscripting accessors that do lookup by an index or key
- Iterators
- Comparisons
- I/o functions
- Protected functions
- Private functions
- Data members (private)
- Static data members (private)
Function implementations in .cc files are in the same order as their declarations in the .hh header.
Interface classes generally have no data members and only pure virtual function declarations (those declared such as virtual bool foo() const = 0; where the =0 implies "pure", meaning no implementation is provided in the abstract class). The (simplified) Polymer interface on the right shows what that looks like. |
|
Simplified Polymer Interface Source
#ifndef INCLUDED_rosetta_conformation_Polymer_HH
#define INCLUDED_rosetta_conformation_Polymer_HH
#include <rosetta/conformation/Polymer.fwd.hh>
#include <rosetta/conformation/Molecule.hh>
#include <rosetta/conformation/HydrogenBond.fwd.hh>
#include <rosetta/conformation/HydrogenBonds.hh>
#include <rosetta/conformation/Residue.hh>
#include <rosetta/conformation/keys/PolymerKey.hh>
namespace rosetta {
namespace conformation {class Polymer :
public Molecule
{
private:
typedef Molecule Super;
public:
typedef PolymerKey Key;
typedef HydrogenBondOP HydrogenBondP;
typedef HydrogenBonds::ConstIterator HydrogenBonds_ConstIterator;
typedef HydrogenBonds::Iterator HydrogenBonds_Iterator;
protected: inline
Polymer()
{} inline
Polymer( Polymer const & polymer ) :
Super( polymer )
{}
public: virtual
Polymer *
create() const = 0; virtual
Polymer *
clone() const = 0; inline
virtual
~Polymer()
{}
protected: inline
Polymer &
operator =( Polymer const & )
{
return *this;
}
public: virtual
void
clear_neighbors() = 0;
public: virtual
Key const &
key() const = 0; virtual
Size
n_residue() const = 0; virtual
HydrogenBonds const &
H_bonds() const = 0; virtual
HydrogenBonds &
H_bonds() = 0;
public: virtual
Residue const &
operator []( Size const i ) const = 0; virtual
Residue &
operator []( Size const i ) = 0; virtual
Residue const &
residue( Size const i ) const = 0; virtual
Residue &
residue( Size const i ) = 0;
public: virtual
HydrogenBonds_ConstIterator
H_bonds_begin() const = 0; virtual
HydrogenBonds_ConstIterator
H_bonds_end() const = 0; virtual
HydrogenBonds_Iterator
H_bonds_begin() = 0; virtual
HydrogenBonds_Iterator
H_bonds_end() = 0;
};
}}
#endif // INCLUDED_rosetta_conformation_Polymer_HH |