Artistic Style
Allman for me, and tabs for indentation.
I've sort of catered and adapted to how I am told to
format code at work.
Code:struct Sample { int x; float y; }; void functionName(int x, int y) { /* blah */ }
Double Helix STL
Pep 8
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
For a long time by style was Allman-like, but I'm trying to switch to 1TBS lately. I find it must more compact and readable.
Devoted my life to programming...
What it's calling java style. Although I always though that was k&r
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Ditto.
Allman style here, with 4 spaces. I tried 2 spaces for a while, but personally found that it made indentation noticeably harder to distinguish. Allman seems to waste vertical space, and some blocks like if-else look weird, but I always disliked the following more:
Depending on what lines 1 and 2 contain, I feel like there isn't enough to distinguish them, and would wish to add spacing anyway. Allman enforces this.Code:for (int i = 0; i < 10; ++i) { int n = 20; // too close, not separated enough someFunction(n); }
Not having a space after control keywords like if also makes these easier to distinguish from the block following them, but it's uncommon to do so.
Allman. I prefer to have matching brackets in the same column.
Another stylistic question: Does anyone here ever use spaces to line up text? e.g.
... versus:Code:struct x { int a; char b; }; // ... void function1(void); int function2(void); // ... x = 4; y1 = 5;
Code:struct x { int a; char b; }; // ... void function1(void); int function2(void); // ... x = 4; y1 = 5;
What about function definitions with lots of parameters? (not always avoidable) Do you break the line when the imaginary (80/100/120 character) limit is reached, or do you put each parameter on its own line?
The insistence to line up code inside parentheses can also get ugly...
...whereas applying only regular indentation to the next line would allow almost any expression to fit into two lines.Code:threadManager.push(std::thread(&myClass::myMethod, this, std::cref(someMember.child()), convert(localVariable1 + localVariable2)));
And what about in-place lambda definitions:
OrCode:std::whatever(I.cbegin(), I.cend(), O.begin() [](const auto& a, const auto& b){ /* code here */ });
Code:std::whatever(I.cbegin(), I.cend(), O.begin(), [](const auto& a, const auto& b) { // code here, but wasteful for simple expressions });
Last edited by Guest; 08-08-2016 at 02:02 PM.
I put breaks at the imaginary character limit. If a function takes so many parameters, though, I strongly reconsider refactoring it. Often it can be made into a class or a struct that's passed around.
If it's a short lambda, thenAnd what about in-place lambda definitions:
OrCode:std::whatever(I.cbegin(), I.cend(), O.begin() [](const auto& a, const auto& b){ // code here });
Code:std::whatever(I.cbegin(), I.cend(), O.begin(), [](const auto& a, const auto& b) { // code here, but wasteful for simple expressions });
If the lambda won't fit on the line...Code:std::whatever(I.cbegin(), I.cend(), O.begin(), O.end(), [](const auto& a, const auto& b){ // code here });
If the lambda is multiple linesCode:std::whatever(I.cbegin(), I.cend(), O.begin(), O.end(), [](const auto& a, const auto& b){ // code here });
If the lambda won't fit on a single line...Code:std::whatever(I.cbegin(), I.cend(), O.begin(), O.end(), [](const auto& a, const auto& b) { // code here });
Code:std::whatever(I.cbegin(), I.cend(), O.begin(), O.end(), [](const auto& a, const auto& b) { // code here });
I do it very often.
On my C++ days I wasn't shy of overloading these. If a function signature could be partitioned, it would. But often this meant the function was no very well designed to begin with, since if I can overload it with a different set of parameters, very likely the function was trying to do more than one thing. Recognizing this, I would then move to actually break the initial function into more discreet functions. (two refactorings to finally fix something I should have detected from the start is my statistical mode... grr)
I can't recall the last time I wrote a function with too many parameters to fit in a 120 character line. But I often have to deal with those when working with a library or when functions ask for certain types of strings. I never multiline the arguments list. For some reason I can't stand the look of it. It's part of the reason I would try to get rid of the ones I wrote myself. But if a function demands that many arguments, or requires a long string, I prefer to initialize variables and pass in their names anytime it results in a shorter caller.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.