While I certainly agree even single line ifs should be braced for safety (no objection regarding that from my side), I also think an analyzer smart enough to add these braces should be smart enough to catch stale gotos and conflicting indentation as well.
Improving clang-format
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Improving clang-format
Cheers,
Markus
Markus
Re: Improving clang-format
I see where you are coming from, and it is an interesting question. Why didn't the Apple person's editor show or highlight that the second goto was out of place, indicating a potential problem?
1. It was 8 years ago.
2. Maybe clang-format integrated in IDE was not a thing for them at that time. If it was the editor would have reformatted (more or less) as he typed and the second goto would have been in the correct place. Not that the formatted code was in error, just not what was intended - but the editor couldn't know that!.
3. goto fail hadn't happened. Yet.
It is only now, eight years after goto fail, that FreeCAD has taken the first steps.
In a formatted edit, it becomes habit after every few changes to format. Quick and easy. It also makes typing easier. Don't know about you, but I consider carefully synchronising space characters to make something look pretty WOFTAM. Easier just to bang your thoughts and format. Better things to do than argue about a space or tab.
Re: Improving clang-format
So far curly braces everywhere appears to be uncontested, which is fantastic.
Next to decide is where they go:
1. for class, function, method etc (separate controls)
opening brace same line / next line
I suggest classes: next line. methods same line (not strong conviction)
2. for one-liners: same line or separate (I suggest separate. Those one-liners on same line are very difficult to spot when your brain is running down the indents etc on the left side).
Next to decide is where they go:
1. for class, function, method etc (separate controls)
opening brace same line / next line
I suggest classes: next line. methods same line (not strong conviction)
2. for one-liners: same line or separate (I suggest separate. Those one-liners on same line are very difficult to spot when your brain is running down the indents etc on the left side).
Re: Improving clang-format
It depends if it's declared in a header or source file. If a class is declared in a header file then in many cases it's a sub-class and there I find it more practical to have the braces in the next line.1. for class, function, method etc (separate controls)
opening brace same line / next line
If you have a small and private class or struct in a source file I usually write the opening brace at the same line as the class/struct name.
For functions/methods it's the other way around. If a function is implemented in a header then I prefer to write the opening brace at the same line while for functions in a source I put the opening brace on the next line.
The actual code of the one-liner should always be written to the next line. It's not only easier to read but also much easier to debug.2. for one-liners: same line or separate (I suggest separate. Those one-liners on same line are very difficult to spot when your brain is running down the indents etc on the left side).
If the function has an argument it's actually not possible to see its content in the debugger if everything is on the same line.
- wandererfan
- Veteran
- Posts: 6268
- Joined: Tue Nov 06, 2012 5:42 pm
- Contact:
Re: Improving clang-format
I like the following, but not a fanatic.
Code: Select all
class myClass
{
void myMethod();
};
void myClass::myMethod()
{
if (myCondition) {
singleLine();
} else {
differentLine();
}
}
Re: Improving clang-format
As said, I have no strong objections about any style, provided it's consistent.
However, I would recommend to start from an existing style/standard (Qt?). No need to reinvent the wheel.
However, I would recommend to start from an existing style/standard (Qt?). No need to reinvent the wheel.
Cheers,
Markus
Markus
Re: Improving clang-format
We're already seeing in ealier posts that the Qt settings are less than ideal. From memory the current settings were based from LLVM, but with 4 char indents, and a couple of changes since.
I think we need to keep pushing. Find consensus on what works for us.
Re: Improving clang-format
Bering relatively new to C++ I have been amazed at the way FreeCAD devs have been jamming up code as tight as possible, avoiding any use of spaces wherever possible, no space lines between methods etc.
Personally I find this painful to read, but I've come to realise its a bit of a pattern in C++ land, particularly older C++ code.
I'm not sure clang-format can distinguish between h and cpp files. I doun't think so, but heh ..
For humble mine, same format everywhere, no special cases KISS.
So can it be done like you suggest? And should it be done that way?