Open AlexanderRichert-NOAA opened 7 months ago
I am very interested to see how this goes and if it works well.
On a past Java project I worked with a team of 10+ programmers. We had a java-formatting program that was automatically applied by the CI system before any code was merged (and this is common in Java development). It helped a lot. Previous to that, programmers would reformat code in minor ways, but this would cause code review to be harder. (BTW we were not using GitHub, which has an "ignore whitespace" setting in code review to help with this problem.)
Programmers have strong feelings about their formatting and indentation habits. But software engineering studies have shown:
So the goal is to pick some formatting not too objectionable to anyone, and then apply it to all NCEPLIBS and (I propose) UFS_UTILS code. We then all have to adjust our editors and habits to match that formatting (probably not too many habits to change as we are all already formatting similarly).
@jbathegit @GeorgeGayno-NOAA what do you think?
I don't personally have any "strong feelings" or objections to anything noted in the fprettify project. So it seems OK to me to consider making further use of it.
Please check out the fprettify'd version of NCEPLIBS-ip: https://github.com/NOAA-EMC/NCEPLIBS-ip/pull/232 I chose some somewhat arbitrary options as far as indentation, whitespace, capitalization, etc., so nothing is set in stone, but I figure this is a good start for discussing what we do and don't want.
Once more of the code is converted to F90 format, I want to explore using fprettify to make the code nice and consistently formatted in terms of indentation, capitalization, etc. So far I like
--case 1 1 1 1 --indent 4 --whitespace 1 --disable-indent-mod --enable-replacements
for the argument (plus a code tweak to lower-case all variables).