remove obsolete section about code formatting, explain clang-format better #1136
Conversation
| ## Preferred Coding Style | ||
| Here we describe our preferred coding style. Coding style is very personal and we don't want to force our views on anybody. But for any contributions to the ROOT system that we have to maintain we would like you to follow our coding style. | ||
|
|
||
| ### Indentation | ||
| To be able to keep as much code as possible in the visible part of the editor of to avoid over abundant line wrapping we use indentation of 3 spaces. No tabs since they give the code always a different look depending on the tab settings of the original coder. If everything looks nicely lined up with a tab setting of 4 spaces, it does not look so nicely anymore when the tab setting is changed to 3, 5, etc. spaces. |
There was a problem hiding this comment.
Consider keeping those 2 non-tool specific paragraphs.
There was a problem hiding this comment.
The first may still be useful indeed, but the second is completely handled by the formatter, no? (meaning that if we enforce the use of clang-format the user doesn't really have a choice on tab vs spaces)
There was a problem hiding this comment.
True but clang-format is not yet (there is hope though) fully supporting the 'real' formatting we want (see in particular the alignment in the header files), consequently we still need to leave the clang-formatting optional and thus some unwanted formatting will still be committed. Most formatting are harmeless-ish and can be most hand done ... the tab vs space is extremely (slight exaggeration) annoying (to me) and can be invisible to (newer) developers, so I would keep it.
On a different note, there is a slight question on whether it is helpful to describe the general/main formatting choices so developers get used to typing it almost correct ... or not. (but we definitively can not expect developers to read the clang-format to know the rules (the .clang-format is too dense and long) ... on the other hand the existing might be a (close enough?) documentation/example)
There was a problem hiding this comment.
I agree that it is good to give developers an overview of the main formatting choices and their rationale; on the other hand the use of an automated formatter should have the main goal of relieving them from having to spend time thinking about it. What about keeping the paragraphs but placing them below the clang format description? And make it clear that if all they care about is submitting "valid" code they can skip them but if they want more details they can optionally read them...
There was a problem hiding this comment.
Yes, reordering in this way sounds fine.
No description provided.