Extending clang-format

Hi all,

First post.

I’ve found clang-format to be a very powerful and useful tool and I’d like to start extending it to support some other formatting styles that I have to work with. The two changes I’d like to start with are to namespaces and function parameters.

For namespaces I’d like create a configuration parameter that would allow nested namespaces all on one line.

Rather than

namespace a {

namespace b {

namespace c{



namespace a { namespace b { namespace c {

and for functions rather than

int foo(int param1,

int param2)


int foo

int param1,

int pararm2

I’ve started to poke around in the clang lib/Format code but I’m finding it difficult to figure out where the best place to make the changes is and there isn’t much documentation on the clang-format design/code I can find.

I think the rough idea in clang-format is to use the UnwrappedLineParser to separate the code into the appropriate lines, then using the UnwrappedLineFormatter annotate the tokens, merge lines where possible and delete unnecessary lines then finally dump it all.

Taking my namespace change for example I’ve made modifications to the UnwrappedLineParser::parseBlock so it won’t always add a newline from parseNamespace

First off, please read:

My initial thoughts on the two requested changes:

Namespaces: This isn’t worth adding the complexity for. Yes, it wastes a bit of vertical space, but it is also in a place in the file where vertical space really doesn’t matter this much. Plus, with C++17, this is going to become a non-issue as you can just declare “namespace a::b::c {”. I feel like there has been an argument about this before.

Function parameters: This goes against some quite fundamental assumptions, that clang-format is making. While it certainly can be done, I’d be hesitant to get this in unless there is strong evidence that the requirements presented in the link are fulfilled.

Sorry, I actually hate being so negative. However, I also want clang-format to remain maintainable and provide the best possible experience for most people.


Hi Daniel,

Thanks for the response. I understand the clang maintainer’s perspective on this issue but I’d still like to attempt to support my formatting styles.
If clang devs decide its not the direction they’d like to take that’s cool but its probably still worth my time to make the modifications to support it - it will save me lots of time :slight_smile:

So if you have any pointers or where to embark on this I’d appreciate it otherwise I’ll continue to wade/experiment my way through.

If I get to a place where its working and its not a dog’s breakfast I’ll give you guys a look and you can make your own mind up, no hard feelings.