So, having messed around in the clang format code and made some patches, here's my two cents:
Clang format is based on,
- parsing the AST using
libclang
, which basically eliminates all whitespace
- breaking up the token sequence into "unwrapped lines" which are like "logical" code lines
- Applying rules / configuration info to sometimes split up "unwrapped lines" into smaller units
- Spit it all back out again with new whitespace / indentation
It's not easy to make it respect the original whitepsace, that sort of gets tossed when you first parse the code.
You can control where it places line breaks, most easily, by
- setting the column limit
- using the "bin pack parameters" options
- setting penalties for various kinds of breaks -- break after return type of a function, break before first call parameter, break a string literal, break a comment...
- placing comments at the end of a line (clang format cannot remove the comment and must therefore split the line)
- use the clang-format off / on directives
Here's one thing you could try:
std::vector<std::string> get_vec()
{
return std::vector<std::string> { //
"this is a test", //
"some of the lines are longer", //
"than other, but I would like", //
"to keep them on separate lines" //
};
}
The advantage of this over // clang-format off
is that, if you later change the tab width or some other option, those code lines will still get those formatting changes so you don't need to manually go into the // clang-format off
regions to fix it. However it's still a bit of a hack, YMMV.
Ultimately, clang-format
is very much about imposing a uniform format over an entire code base, making sure that all string literals are formatted in the same style everywhere in your program. If you want to have micro-level control over line-break decisions, that's not really in the spirit of the tool, and you'll have to do things like disable it.
This can sometimes be frustrating esp. when you want to do things with arrays and have columns aligned or something -- for instance, here's some natural code from lua C api:
static luaL_Reg const methods[] = {
{"matches", &dispatch::intf_match_unit},
{"to_recall", &dispatch::intf_put_recall_unit},
{"to_map", &dispatch::intf_put_unit},
{"erase", &dispatch::intf_erase_unit},
{"clone", intf_copy_unit},
{"extract", &dispatch::intf_extract_unit},
{"advance", intf_advance_unit},
};
When clang-format runs over that, it's generally not going to align the right column, its going to place it a fixed number of spaces after the commas and there's not much you can do about it afaik.
Or, if you have 4 x 4 matrix for use with OpenGL:
constexpr float shadow_skew_hardcoded[16] =
{ 1.0f, 0.0f, 0.0f, 0.0f,
0.5f, 0.5f, 0.0f, 0.0f,
0.0f, 0.0f, 1.0f, 0.0f,
0.0f, 0.0f, 0.0f, 1.0f };
If you let clang-format run over things like this it's just going to mangle them, and afaik there's no easy way to make it format them nicely, so you just have to resort either to the "lots of trivial comments" hack, or use clang-format off when you have something like this. These are just intrinsic limitations of the tool. If you aren't happy ever to have to do things like that then it's probably not the tool for you.
AllowShortFunctionsOnASingleLine: None
will work. – Variformmain
but I'm more concerned about the vector initialization in general. If the vector was initialized this way in another (longer) function, it would still get unwrapped. – MulticolorAllowShortFunctionsOnASingleLine: None
,main
is no longer unwrapped, but as you can see the vector initialization still gets messed up. – Multicolorreturn {"this is a test",
... – Ochrea//-
to the line break that I want to preserve. – Younglove