Rules coding for SURFEX-Crocus¶

If you plan to code in SURFEX-Crocus and to share your work, you must respect 3 main ideas:

• CODE: Readability counts
• TEST: Errors should never pass silently
• COMMENT: Now is better than never

CODE¶

• follow the general rules for SURFEX : https://www.umr-cnrm.fr/surfex/spip.php?rubrique93 and in particular the DOCTOR norm for prefixing variables.
• No spaces at end of lines
• No tabulation
• Always ENDIF after IF. Indeed, FORTRAN allows a IF instruction in only one line but it can disturb some IDE tools resulting in bad automatic indentation
• Same for DO/ENDDO and WHERE/ENDWHERE
• Two spaces for indentation in IF/DO/WHERE etc...
• Number of columns shouldn’t be more than 100
• Proposal : one line for each dummy variable in declaration. Always comment what is this variable, give the unit involved.
• For the CALL of routine, we should have a rule for the « & column » -> has to be decided.
• Please separate commit for indentation/rule coding and commit for science (implementation of new physical scheme, implementation of diagnostic).
• The actual SURFEX-Crocus code is not respecting these rules. We DO NEED YOU to help us getting the code as clean as possible. If you’re OK to do your part on rule coding, this would be awesome.

TEST¶

Snowtools provides some developments test for surfex. Please use it to check that your devs don't break something and please add one of your test.

Test your modifications¶

cd $SNOWTOOLS_CEN/snowtools/tests
python3 test_dev_surfex.py

Implement a new test in order to secure your developments¶

We just need a namelist and a FORCING File to add your devs to test_dev_surfex.py
If it is possible to use the FORCING used in the First Test, this is better

COMMENT¶

Please comment your code in the Fortran files. It is useful to have the units involved.
You can add some infos in the Development_in_progress page and if some diagnostics are specific to your devs, please also add some infos in the CSELECT page: About_CSELECT_options