search

CompEvol / beast2

Bayesian Evolutionary Analysis by Sampling Trees
www.beast2.org
GNU Lesser General Public License v2.1
240 stars 84 forks source link

Naming Conventions #357

Closed Anaphory closed 9 years ago

Anaphory commented 9 years ago

It regularly catches me off that it is beast.core.parameter and beast.core.datatype vs. beast.math.distributions and beast.evolution.operators, or that some operator names are of the form XyzOperator, some are just Xyzer (TipDatesScaler) and some (like Exchange, or Uniform which clashes with the distribution of the same name, but UniformOperator also exists) have no such ending at all. This is mostly a thing I just stumbled over when trying to translate a beast 1 configuration file into beast 2 xml, which involved some double checking of the precise names of various objects. Are there any conventions for beast2 for package names, class names and input names, so that I can follow them and not make matters worse in my own extensions?

tgvaughan commented 9 years ago

The file README.md contains a link to a page discussing coding style. However, it seems that this link is currently broken due to the beast2.org site upgrade. We'll have to fix this.

Anaphory commented 9 years ago

Of those coding style rules,

Package Names are all small letters. This means word boundaries may be difficult and packages should attempt to be single word names if possible (and probably no more than 2).

is relevant to my question, and tells me I should indeed rename my splitandmerge package.

Class Names are unique under a same path in the entire name space including BEAST 2 core, all depended packages and 3rd party libraries. A duplicated class name has to be created in a different path. For example, beast.math.util.MathUtils and org.apache.commons.math.util.MathUtils are fine, but you cannot create a class MathUtils again under the path beast.math.util in any other packages. tells me that Uniform is not a problem according to the coding style, but I saw stated somewhere else (https://github.com/CompEvol/morph-models/issues/1) that extensions should use a different path structure anyway, so how can name conflicts like this happen in the first place?

As a concrete example, given that splitandmerge is three words and thus a non-conform name for a package containing a class for a split operator and a class for a merge operator, what should it be called instead? The package containing the operators in beast2 is called beast.evolution.operators, but most other packages have singular names, so should it be operator instead?

tgvaughan commented 9 years ago

There is a degree of inconsistency in some of the beast package names, true. For this reason, I wouldn't worry too much about which particular standard to stick to. Just try to make your own package as self-consistent as possible.