mifads
commented
8 years ago 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
We need to write "down the law" on issues such as:
end if/end do/&c vsendif/enddo/&c_mlending?