Coding Style

[ctieben]

I would perform to find a common coding style for sempr to have clear and readable code.
In most cases a clear style also helps the developer and reviewer to avoid bug.

Some example coding style:

• https://google.github.io/styleguide/cppguide.html
• http://llvm.org/docs/CodingStandards.html#beware-of-non-determinism-due-to-ordering-of-pointers
• https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

[ctieben]

About whitespaces between pointer:
http://www.stroustrup.com/bs_faq2.html#whitespace

[niniemann]

Fun fact (not an argument, neither for nor against introducing a style guide):
I just ran cpplint (which is supposed find nonconformities to the google style guide) on our src/ and include/ directories: Total errors found: 2272
😅

[y0urself]

And the google style guide should accept both int* i; and int *i; (at least in different files).
(https://google.github.io/styleguide/cppguide.html#Pointer_and_Reference_Expressions)

So I think this whitespace discussion is really unnecessary.

But an overall coding style is useful.
Like:

void foo()
{
}

or
void foo() {}

or
void foo () {}

And all the other things ...

[ctieben]

As before I'm sorry for opening the topic about white-spaces between pointer. I was far to strict to comment this and there is no right or wrong in this question.

I will vote for the Google C++ Style Guide 👍 . Its well defined, modern and compact.
For example see the formatting function and formatting conditions sections.

[y0urself]

But you mentioned it again. :D

Yeah I also think the Google C++ Style is a good option. Maybe there is something like Beautify from JS ...
Yes there seems to be something. Maybe this works: https://github.com/xuy/google-astyle ... :)

That will be really hard for me, to not open the curly bracket in a new line.
So this will also be one of the restricts, that caused so many errors @niniemann :

The open curly brace is always on the end of the last line of the function declaration, not the start of the next line.

[niniemann]

I'll have a look at the google-style-guide later. But on a first glance there are already some things that bother me... 😅
E.g.:

Each line of text in your code should be at most 80 characters long.

I know the reason, but come on! Today, on widescreeen monitors, 80 is really not much :D I think I currently use 100 or so. ^^

Use only spaces, and indent 2 spaces at a time.

Maybe my eyes are just too weak, but I really prefer 4 spaces. 🤓

Just to mention two obvious things. More on that later. :)

[y0urself]

I like 2 spaces. I think that is really enough and the code will not move out of the screen so fast.

I agree with the 80 characters. But we need to provide compatibility with the code of the 60th! :D

[niniemann]

If your code becomes so deeply nested that your 4-space-indentation starts to create conflicts with the 100-(:wink:)-chars-per-line-limit, you should really reconsider your software design on a different level. :D

[y0urself]

Yeah 100 seem to be okay, but 80 and OOP?
Some vtkSmartPointer declarations are longer than 80 characters ... and with two indentations there are 72 characters left ... that is really nothing ...

[ctieben]

A style guide is more a recommendation than a law.

And I know a guy who always split the code to the left and right side of his monitor ;-)

But the limit protect you form 1 line complex functions or large 1 line if conditions or overall to long conditions. I wouldn't pay to match attention of 80 or 100 how long its not to long. Sometime with OOP and Namespaces it could be difficult to hold the limit.

[niniemann]

But if we say "we use the google style guide, but with the following exceptions: [...]" everything gets really messed up. No more automatic linter/tidy, and a real pita overall.

Hey, I often split my editor into all 4 quadrants of my monitor... ^^

So you wouldn't want to say "fixed limit: <N> chars per line", but rather "be reasonable. Don't make your lines way too long."? We don't need a style-guide for that. 😉

[ctieben]

To push this topic a bit.
I like to create a .clang-format file which allows editors (like Atom or VS Code) to auto-format the code.

[niniemann]

This would be one steps towards the "how to enforce/apply the style-guide", but we still didn't find a common base on "what should be enforced". See my previous comment: If we cannot explicitely say "that's what it must look like!", but rather say "We don't care too much, just be reasonable", there's no way to encode the latter in a style-guide / formatting options.