Thread: What's your indentation style?

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 */
}

Pep 8

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.

What it's calling java style. Although I always though that was k&r

Allman with tabs (4 spaces wide) because it makes code clear and easy to read to me. It clearly shows where blocks begin and end, which is the biggest reason I like it.

Originally Posted by Matticus

Another stylistic question: Does anyone here ever use spaces to line up text? e.g.

Generally, no. But sometimes I have been known to do that. It is rare, though.

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...

Code:

threadManager.push(std::thread(&myClass::myMethod, this,
                               std::cref(someMember.child()),
                               convert(localVariable1 +
                                       localVariable2)));

...whereas applying only regular indentation to the next line would allow almost any expression to fit into two lines.


And what about in-place lambda definitions:

Code:

std::whatever(I.cbegin(), I.cend(), O.begin()
              [](const auto& a, const auto& b){ /* code here */ });

Or

Code:

std::whatever(I.cbegin(), I.cend(), O.begin(), [](const auto& a, const auto& b)
{
    // code here, but wasteful for simple expressions
});

Originally Posted by Guest

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?

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.

And what about in-place lambda definitions:

Code:

std::whatever(I.cbegin(), I.cend(), O.begin()
              [](const auto& a, const auto& b){ // code here });

Or

Code:

std::whatever(I.cbegin(), I.cend(), O.begin(), [](const auto& a, const auto& b)
{
    // code here, but wasteful for simple expressions
});

If it's a short lambda, then

Code:

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 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 lines

Code:

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
    });

Originally Posted by Matticus

Another stylistic question: Does anyone here ever use spaces to line up text?

I do it very often.

Originally Posted by Guest

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?

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.