Automated indenting and emacs + coding style iHAMOCC

[mvertens]

@JorgSchwinger - it is possible to auto-indent all of blom or just the hamocc part of blom with emacs.
For example - see https://unix.stackexchange.com/questions/162057/can-i-have-emacs-automatically-indent-my-whole-code-after-it-is-all-written. Emacs can also be run through every file offline in a script to do this. This was actually done for ww3 recently as part of a big reformatting effort.
There might be a way to have the do loop structure in place that you want - but I'm not sure how to do it. The nice thing about the emacs capability is that it could keep the code indented consistently without a lot of extra work.

[jmaerz]

@mvertens , thanks for opening the issue. Just as a comment, I fear the line length issue fixed in #293 was stemming from emacs auto-indention and line arrangements - such issues need to be avoided, if we go this route.

[mvertens]

@jmaerz - this was my mistake in compressing lines. This was not emacs auto-indent. Sorry about that.

[jmaerz]

No worries, I just realized it when doing the hotfix that some un-expected behavior probably went on.

[jmaerz]

Hi @JorgSchwinger, @TomasTorsvik , any further thoughts on this? - I am asking since the initial idea was that some code cleanup would be nice to have for the final CMIP6-compatible iHAMOCC version - as a starting point for the merging process of master into beyond-CMIP6 and also the nitrogen cycle into beyond-CMIP6, which then all will be pushed to master, once tested. I guess, another way to go for now would be just a cleanup of the use statements, which you suggested earlier (or leave the code as it is and merge master into beyond-CMIP6 to enable working on that side). See also #289 for the merging strategy. I am personally agnostic on this - I see the benefit of both ideas while I try to adapt to the chosen style (as long as we don't write everything with the same indent or use tabs for indenting :-D).

[mvertens]

I think I can get emacs to do the type of do-loop indentation that @JorgSchwinger wants. I just need to prototype it.
The a script would do the indentation across the system - without anyone actually having to learn emacs. But I am fine with whatever makes sense in terms of priorities.

[JorgSchwinger]

I am not insisting on the specific do-loop style. This was how the HAMOCC code was originally written - I got very used to it and think it makes some sense - but we can abandon it. (BLOM has something similar though, where certain do-loops are not indented)

Regarding the automated stuff, I would be worried a bit about indentation of continuation lines. These are often not following a standard indentation for a good reason - to vertically align with lines above. This really increases readability a lot. I fear this will be lost with the automatic procedure?

[mvertens]

Can you clarify what you mean by standard indentation and not vertically aligning with the lines above. I actually used emacs auto-indentation for a lot of the refactoring I did - and I think it did the vertical indentation correctly. I think I'm not understanding what you mean.

[jmaerz]

Here a compiled list of thoughts provoked by #299:

• How much indent per code block (I would also opt for 2-3)
• Some routines/modules still have the +7 F77 indent, which could be changed to a smaller indent - or do we want to totally migrate any F77 (*.F) files to F90 free format files and have consistent formatting across BLOM
• I agree with your 'indent by meaning approach' when aligning following up lines, which likely would mean no automated indention via emacs. Alternatively, aligning following up lines could be done quickly after a pass of auto-indentation. This would be much easier and maintainable long term than hand editing each file.
• Wrt spatial loops: any way is fine, I would say.
• I would be in favor of aligning comments to code blocks (to not break the visual code flow) - similarly, one could think about OMP directives
• small versus capital writing of Fortran commands (as written before, I would prefer capital for module, contains, implicit none, potentially subroutines, the rest I would be fine either way - like integer, float, if else endif constructs)
• Indention of comments on subroutines and modules?
• minor: how much space between code in case of =, **, *,/ and +,-
• individual alignment of some code regions (e.g. aligning = for a number of lines in case of differently long variable names in front - I would be in favor of accepting or even enforcing this).
• Not related to indenting: but to coding in general: avoid hard-coding numbers (e.g. stoichiometric ratios should be used as parameters)
• shall we aim at having a module defining working precision (in common with blom++) to enable using floating point numbers like 1.0_wp?
• Generally: which line length to apply?

I guess, I didn't know, how much I would appreciate some code cosmetics :-D

In the course of the code maintenance, we can potentially also think about rewriting some of the last subroutine files into module files, while I would opt for keeping the the name and number of files (just add a mo_-prefix).

I just talked to @JorgSchwinger, further suggestions on his side:

• How about headers in modules (and subroutine files) - shall we stick to the 'changes' log style? - or what instead?

Link to former iHAMOCC coding practice: https://github.com/NorESMhub/BLOM/blob/master/doc/coding-guidelines.rst - which can then be updated accordingly.

[JorgSchwinger]

All very good points, and I don't think it will be difficult to agree. I would leave out the 1.0_wp though since this this would need to be coordinated with BLOM(?) and has implications for compiler options. As items to discuss/clarify I would add:

• continuation lines (use of trailing &)

[jmaerz]

Thanks for the input - the _wp is more of a long(er) term issue (as some others potentially as well).

[jmaerz]

@mvertens , @JorgSchwinger , @TomasTorsvik , after talking to @JorgSchwinger and as suggested by @mvertens , it would be good to have a zoom-meeting next week on i) regression testing and, after opening the can of worms with iHAMOCC coding style ii) some coding style practice. Since from the iHAMOCC side, we are almost ready for NorESM2.1 that just contains bugfixes (once merging current master into beyond-CMIP6 and doing some minor code cosmetics there as well due to the bugfixes), there seems to be a bit of room for taking a bit more care for code cleaning and maintenance, having then a decent code base for the future on the iHAMOCC side - which speaks for keeping the momentum on this and trying to push even further, once agreed on some coding style. In any case, I am looking forward to a discussion on this, ideally early next week.

[mvertens]

I have prototyped a simple first pass through of emacs auto-indenting (which took about 1 minute to be carried out). If you want to look at it before the call see - https://github.com/mvertens/BLOM/tree/feature/new_formatting.
One option would be to start with this and do a subsequent pass through to implement other custom changes.

[jmaerz]

Dear @mvertens , would you mind opening a DRAFT pull request (which can be closed again afterward)? - to better see the changes?

[jmaerz]

Nevermind, I just realized, I can see theme anyway.

[mvertens]

Absolutely. I was not sure if I should do that. I've create a new PR with an updated branch for the head of master.

[mvertens]

Please just have a look at the new PR on github. That has the most recent master with the formatting.

[jmaerz]

Hi, I opened a draft PR as a starting point for capital versus small letters in Fortran code, see: #304

[mvertens]

@matsbn - I have reformatted the HAMOCC code to have all subroutines in modules and to have all the code be indented coherently as well as be F90 compliant. I am wondering if I could take on doing the same thing in the rest of the BLOM code. It took be about a day to do this for HAMOCC and I think it would only take me a day or so to do it for BLOM. It would be nice to have everything consistent across the BLOM code if possible. Please let me know what you think.

[TomasTorsvik]

I think the changes introduced in HAMOCC recently has greatly improved the ease of navigating and maintaining the code base.