Code formatting about vic HOT 9 CLOSED

Sounds good to me.

On Tue, Aug 20, 2013 at 8:49 AM, bartnijssen [email protected]:

I suggest that we adopt some standard for VIC code formatting for a few
reasons:

a) a mixture of tabs and spaces is currently used for code indentation,
which depending on the individual users editor settings (tab size, etc.)
makes for code that is very hard to read.

b) a lot of the code has trailing whitespace that some editors will auto
remove (again depending on user settings). This leads to non-significant
whitespace changes in the code, which in turn result in harder to read
diffs in version control (since you may have to plow through many
whitespace changes).

Rather than coming up with a long list of code format requirements, I
suggest using a code formatting tool: uncrustifyhttp://uncrustify.sourceforge.net/,
which everyone would run with a standard configuration file (which itself
will be included in the VIC git repo), before committing changes.

My suggestion is to implement this as part of VIC 5 rather than 4.2, to
avoid a gazillion whitespace changes in 4.2. VIC 5 will be a major change
anyway. I can make my configuration file available.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48
.

from vic.

I just ran a test of uncrustify with a standard configuration file on the VIC source code directory and I really like how the code looks. I also agree that we should wait to implement this until a major release (5.0) because this could change many lines of code (my test changed about 80%).

from vic.

Yes, also see this link for my version of the config file for C. I tweaked
it a bit.

Bart

https://www.dropbox.com/s/4xb2ycs2izpjy9w/uncrustify_c.cfg

On Tue, Aug 20, 2013 at 12:30 PM, Joe Hamman [email protected]:

I just ran a test of uncrustify with a standard configuration filehttp://uncrustify.sourceforge.net/default.cfgon the VIC source code directory and I really like how the code looks. I
also agree that we should wait to implement this until a major release
(5.0) because this could change many lines of code (my test changed about
80%).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-22966766
.

from vic.

I am wasting way too much time on this. It turns out it is actually rather difficult to make the code look exactly the way I like. For example, should we make all the comments consistent (a lot of work and probably not worth it), all the lines a maximum width (I hate lines that scroll off-screen and prefer a max width of 80 for everyhting), etc. There are a lot of options in uncrustify and while some make things better in most cases, they make things worse in some cases.

The whole point of running uncrustify is a) to obtain readable code (in particular consistently indented and braced code) and b) to minimize the number of unnecessary commit that are basically just code formatting related.

I think using the uncrustify configuration file that is currently in the archive serves the purpose. Please take at the code in https://github.com/bartnijssen/VIC/tree/feature/issue_48 to see if you agree, so I can move on. This is probably not worth the time I am spending on it, since the indentation is the main issue for me.

In particular take a look at:

https://github.com/bartnijssen/VIC/blob/feature/issue_48/src/calc_surf_energy_bal.c

and browse some of the other files. Note that there is a setting to align on the '=' sign, but again this is difficult to get right in general.

By now I have played with the configuration file and reformatted the code about 20 times, but I am now back to where I started ...

from vic.

I think merges from 4.x to 5.x (which will happen frequently over the next few months during development) will actually be difficult (i.e. lots of conflict) if part of our code is before uncrustify and part of it is after. I almost wonder whether it would be quicker and less painless if we ran uncrustify with the same settings on all branches once and then simply move forward ..... The disadvantage is that files will show massive changes that have nothing to do with functionality.

Alternatively a) we do all development for the time being without the reformat and do it after the migration to 5.0 or b) one person keeps merging 4.x into 5.x from time to time. One possibility might be to follow b) and run uncrustify on the 4.x code before the merge into 5.x. Unfortunately I just tried this and it was not quite as clean as I would have hoped.

Basically I don't want to have to keep dealing with the formatting problem forever. If anyone has any suggestions or wants to take this one let me know. I am shelving it for now on my end and moving on.

from vic.

How about this: wait to do the uncrustify until the major code changes that are slated for 4.2 have been finished and merged into 5.0.

If I understand correctly, the major remaining changes on 4.2 are:
remove dist_prec - almost done
timeseries of veg params - almost done

from vic.

Good suggestion - let's go with that. Which means I'll shelve it for now and when the time comes we can just run uncrustify with the configuration that we already have.

On Mar 31, 2014, at 10:35 PM, Ted Bohn [email protected] wrote:

How about this: wait to do the uncrustify until the major code changes that are slated for 4.2 have been finished and merged into 5.0.

If I understand correctly, the major remaining changes on 4.2 are:
remove dist_prec - almost done
timeseries of veg params - almost done

—
Reply to this email directly or view it on GitHub.

from vic.

I assume that uncrustifying 5.0 but not 4.2 might confuse automated merge tools. But presumably small changes like the other things slated for 4.2, or hotfixes, can be ported by hand...

from vic.

closed via #169

from vic.