Do you by any chance know how to add this custom template through the ClangFormat-Xcode approach (so that it would appear in the drop-down list of formatting options)?

Including a formatting file with Cinder sounds like a good idea to me (golang has a formatter built in, which honestly makes me thank them for not allowing me to worry about that, though I don't really do anything in go).

There's also ClangTidy which is sort of a linter, but will also transform your code if you pass the -fix flag. It even does some crazy stuff like transforming raw loops into range-for when it knows it's safe to do so.

But if anything else, we could indicate that such a .clang-format file would be a great place to start in reformatting some code before issuing a pull request.

There are only 2 things in the style guide that I've found to be unsupported by ClangFormat. There's no option AFAICT to insert a space after the bang (!) operator. Nor can it indent the names of multiple consecutive function declarations.

It's a pity that there is no separate style for return type pointers. With "PointerAlignment: Right", this is what a function declaration looks like:

const ci::gl::Texture2dRef &getTexture() const { return mTexture; }

instead of the preferred:

const ci::gl::Texture2dRef& getTexture() const { return mTexture; }

There is also no setting to add a space after the not operator:

if( ! bEditable ) {

}

Finally, I've changed the following settings in my style script, which align declarations using spaces:

AlignConsecutiveDeclarations: true

UseTab: ForIndentation

Code then looks like this:

I agree that it would be great to include with Cinder

I've started a fork that takes a shot at integrating ClangFormat support:

https://github.com/kitschpatrol/Cinder/tree/clangFormat

See the readme for more info:

https://github.com/kitschpatrol/Cinder/blob/clangFormat/README%20CLANG%20FORMAT.md

This fork includes a .clang-format config file based on notlion's gist + Paul's suggested changes. ClangFormat was run on all Cinder-owned files... the diff is pretty massive. (This is a discrete commit so it's easy to roll back.)

It adds a python script to run formatting on the whole repo, and bundles the ClangFormat 3.8 binary. (Mac only for now...)

Paul's caveats still apply... another big issue is that macros aren't nicely indented. A bug's been open about this for a few years: https://llvm.org/bugs/show_bug.cgi?id=17362

Richard as you've said it would be great to come up with a .clang-format config that would exactly match Cinder's existing style rules — but I think the advantages of consistent and automated formatting might outweigh finding a perfect match over the longer term.

In my opinion it helps enough just to make the file available to contributors.

I had missed some of the third-party code in the blocks directory, which is why Box2d etc. were touched. These directories are now ignored by ClangFormat in the fork.

Adding .clang-format to the repo's root might be confusing if the files in the repo don't actually follow it? Would we just end up with the same noisy diffs on a file-by-file basis if contributors respected the repo's .clang-format when editing files? Or would it be something that people would be expected to only use on new files, necessitating very scrupulous use of any ClangFormat IDE plugins? (Would it make more sense in a subfolder so that it's not invoked accidentally by such plugins?)

I tried to structure the fork so that you can run clang-format -style="file" on any file of the repo and get "correct" behavior when clang-format searches up the hierarchy for a config file — E.g. third-party files are untouched, cinder-owned files are correctly formatted. This would also make it trivial to run clang-format as part of a pre-commit hook or similar.

Anyway, wanted to put this out there to see if anyone felt that an epochal diff might be worth it in exchange for eliminating format-related noise (and cognitive overhead) going forward. "Nope" would not be a surprise. : )

But if a certain chunk of code is particularly ill formatted, I could see running the script on that and issuing a PR for those updates. It might need some hand tuning afterwards to fix things like what I mentioned above.

Also is it required that the clang-format file live in the root of the directory? Seems like it would be nice to keep that as clutter free and put something like this in the tools directory.

Alignment with tab characters is an option, but it results in a combination of tabs and spaces being used to get precise alignment.. Probably not something we want.

Anyhow, if we can't really reproduce the Cinder code style accurately, and are unwilling to adjust said style including a clang-format file is DOA. But like Paul I'll continue to use one in my own projects, and for code contributions (with perhaps some hand editing).

Richard, in a typical invocation, ClangFormat climbs directories from the source file it's called on until it finds a .clang_format file to use. So I think putting it in the root would only make intuitive sense if we actually ran the entire code base through the formatter. Since that's out, I think dropping it in /tools with some explanatory documentation makes the most sense.

Also just for posterity, you can explicitly exclude code from clang-formatting at the line level by wrapping it inside // clang-format off and // clang-format on comments. (Though obviously this is not a tractable fix for the number of mistakes and exceptions we're currently seeing in the formatted fork!)