Coding style to distinguish class member variables about hiop HOT 11 CLOSED

agree. I think I've changed the coding style at least one time as I worked on different project over the years :). do you have a coding style document/link?

from hiop.

It would be my preference to use this style guideline. Would you two mind taking a look? We could add clang-tidy scripts to help us all write conformant code if that sounds good to you both.

from hiop.

I agree with @ashermancinelli, the guidelines he referenced are becoming a gold standard pretty much. The relevant chapter for this discussion is I think in Naming and Layout Rules chapter.

The only amend I would make is to use Allman style, rather than K&R, simply because it leads to a code that is easier to read in a large editor window.

In the end it is all very much a matter of personal taste. The most important thing is that we are all consistent.

@cnpetra in the short term, it would be very helpful if you could set rules for distinguishing member from local variables.

from hiop.

I too prefer Allman style 😄 we could add some scripts for formatting errors when in HIOP_DEVELOPER_MODE to extend what Cosmin and I discussed in #22 . clang-tidy has a options to enable cppcoreguildeline warnings by default, and I have it installed on marianas and newell.

from hiop.

cppcoreguildeline seems to be not very specific but it would be of value if we can enable code style warning/checking in DEVEL_MODE.

I am taking a shot below, please feel free to comment and suggest specific additional guidelines

indentation

• my personal preference is for compact K&R (no separation of between "if" and "("), similar to C, but I am willing to switch to Allman (as long it can be enforced via clang-tidy or similar tool)
• two spaces alignment, maybe four if you like it better, but do not use tabs

naming

• classes: Upper and lower case, no underscores
• data members: ending in _; lower case only and use _ to separate
• member methods: lower case only and use _ to separate

to be continued...

from hiop.

it wouldn't hurt to look at M-FEM dev-guidelines. Consistent code styling enforced via make style and based on Artistic Style.

from hiop.

@cnpetra what you suggest sounds reasonable. As I said, the most important thing is that we are consistent.

A couple of more references that might be helpful:

• The most detailed guidelines that I've seen are published by Stroustrup for JSF program. These are a bit old and may not address recent C++ features. This seems to be a precursor to cppcoreguidelines.
• From ECP family, there are NOX/Trilinos style guidelines that might be relevant for HiOp.

from hiop.

What naming convention for feature branches would be preferred? For example, always branch from master and name the branch <feature or fix>-dev

from hiop.

feature-developmentname or fix-bugname would do I guess. I use dev/devname and fix/fixname, but not for particular reason.

always branch from master, indeed, and master serves as stable for now.

from hiop.

I will change the PR accordingly. I prefer -s over /s so not to confuse ref pathnames and remotes with branch names.

from hiop.

closing this -- the discussion moved to the PR and we're in some kind of (initial) agreement

from hiop.