coding style guidelines

[avaldebe]

We need to write "down the law" on issues such as:

• end if/end do/&c vs endif/enddo/&c
• Module naming: should we rename the modules loosing the _ml ending?

[mifads]

Some points:

• Style.

It would be a very long set of rules to cover everything, but we do have some suggestions on style in the ProgStructure and Progrules docs in Manual. A good practice though is to try to keep the style consistent with what came before, thus "end do", "end function" over "enddo", "endfunction". Actually my own style (and hence EMEP's until recently...) was based largely upon F:

https://en.wikipedia.org/wiki/F_(programming_language)

Although relaxing some constraints (e.g. F doesn't allow 1-line if statements), this F-language base ensures we use only modern fortran.

• Please....

The one thing I would really like people to learn is to avoid hard-coded indices (such as the EC_C_WOOD type stuff in Derived), since this (i) often messes up chemical schemes that don't have such species, (ii) the hacks we have such as iadv_EC_C_WOOD and find_index in Derived_ml are just asking for trouble, since the names can change frequently, and (iii) most importantly, with the groups system we have we can loop over any particular groups. In this case, if EC_C_WOOD has say EC or WOOD in its GenIn.species, we can handle this as part of loops over all EC and/or WOOD species.

• Future

In the near future I will try to merge the EMEP and ESX and python-based GenChem/BoxChem systems. A key part of this is to have modules which can span all systems. These should be stand-alone where possible, or at least not depend on netcdf and MPI libraries. A big advantage of having e.g. box models is that we can test parts of the EMEP code quickly, and even get non-EMEP people to try and give feedback. So, when writing modules, consider non-EMEP applications too,

[avaldebe]

Found the following best practices document

[mifads]

_m, _ml, _mod, or nothing?

The best practice document above suggests using _t for type and _m for module. I agree with _t, but am moving towards _mod for module. This is used by GEOS_Chem and I think it just 'looks pretty' compared to _ml.

As essentially all of our code is in modules we could skip the suffix, but maybe we should keep something for compatibility with the various style guides. Here's another one

(WRF_Chem uses module_ as prefix, which seems like a waste of characters.)