Skip to content

Inconsistencies in naming conventions in dune-istl

Classes in dune-istl seem to follow the CamelCase naming scheme used throughout Dune. However free functions and member functions, as well as data members and aliases, seem to be an arbitrary mix between something like STL-style naming conventions (all lowercase or lowercase+underscore) and "Dune naming conventions" (camelCase). Differences even occur in the same scope and in the same file (without visible reason).

For example:

  • dune/istl/io.hh contains the free functions
void recursive_printvector(..);
void printvector (...);
inline void fill_row (...);
void print_row (...);
void printmatrix (...);
void printSparseMatrix(...);
void writeMatrixToMatlabHelper(...);
void writeMatrixToMatlab(...);
void writeVectorToMatlabHelper(...);
void writeVectorToMatlab(...);
  • dune/istl/common/registry.hh (addressed in !350 (merged)) contains a macro (usually all uppercase in Dune)
#define registry_put(Tag, id, ...) ...

and the free functions

auto registry_get(...);
int addRegistryToFactory(...);
  • In dune/istl/bcrs.hh, Dune::BCRSMatrix has the typedefs
typedef Imp::CompressedBlockVectorWindow<B,A> row_type;
typedef ::Dune::CompressionStatistics<size_type> CompressionStatistics;

and the public data member

static constexpr unsigned int blocklevel = ...;

the public member functions

beforeBegin ();
beforeEnd ();
void setBuildMode(BuildMode bm);
void setSize();
void setImplicitBuildModeParameters();
CreateIterator createbegin ();
CreateIterator createend ();
void setrowsize ();
void getrowsize ();
void incrementrowsize ();
void addindex ();
void setIndices(...);
real_type frobenius_norm2 () const;
real_type infinity_norm() const;
N ();
M ();
nonzeroes();
BuildStage buildStage() const;
BuildMode buildMode() const;

and some private member functions like

void allocateData();
void implicit_allocate(...);

This mix looks unprofessional/ugly to me and makes it harder for users to guess the correct name of a function. It also makes the code harder to read because you wonder what the difference between two functions is that have different naming scheme ("something should be different right? because it looks different..."). I think I listed some rather surprising cases above.

Does it make sense to unify the naming scheme? Deprecate old names and promote new names? Or is that not bothering anyone else (enough)? Which naming scheme would be appropriate (I would guess camelCase for functions to be consistent with the rest of Dune. However there are also interfaces in dune-common like DenseVector::two_norm which are not camelCase although they are Dune-specific types. I'm willing to do some cleanup work if someone cares and the objective/rules are clear.

There is has been a related discussion about some of the dune-common types in dune-common#83 (closed). So there might be already some rules that were decided on that I don't know about...