Convention for wrapping code lines?

Question

I usually wrap my code lines so that they are up tp 80 characters long.

Which wrapping looks better to you?

// (A)
std::vector<MyLongClassName::size_type>* myvector
    = new std::vector<MyLongClassName::size_type>();
bool isOneOrAnother = hereIsOneLongCondition
    && hereIsAnotherOne;

// (B)
std::vector<MyLongClassName::size_type>* myvector =
    new std::vector<MyLongClassName::size_type>();
bool isOneOrAnother = hereIsOneLongCondition &&
    hereIsAnotherOne;

I know it is arbitrary, but is there a convention or a preferred way?

Answer 1

I personally refer to put any operator at the end of a line. Microsoft also recommends this practice, I believe, though I can't find the page at the moment. The C# style guide here, however, recommends the same thing...

When an expression will not fit on a single line, break it up according to these general principles:
# Break after a comma.
# Break after an operator.
# Prefer higher-level breaks to lower-level breaks.
# Align the new line with the beginning of the expression at the same level on the previous line.

Going my memory, most of the code I've read tends to follow this rule too. If you're looking for rationale behind this, the only thing I can really offer is that it doesn't make sense to start a line with an operator because you're effectively starting a new (sub-)expression, and thus makes it easier to separate mentally. Also, if someone is reading code line by line, it's easier to notice a line continuation if there's a hanging operator at the end of the current line, rather than the start of the next line.

Hope that helps.

Answer 2

I'd choose (B), but for the boolean, I might add not-completely-necessary parens and then line the values up within them. I'd add the parens only because my emacs won't do it for me without them.

bool isOneOrAnother = ( hereIsOneLongCondition &&
                        hereIsAnotherOne );

Answer 3

Another possibility for the 2nd statement (sometimes):

bool isOneOrAnother =
   hereIsOneLongCondition && hereIsAnotherOne;

Answer 4

I'm another one who prefers (B) but for the second statement I prefer:

bool isOneOrAnother =
         hereIsOneLongCondition &&
         hereIsAnotherOne;

The reason for preferring (B) comes from being used to javascript's <cough> broken </cough> semicolon insertion syntax. Since I often work in a multi-language environment it is bad for me to acquire habits that breaks one of the languages I use.

Answer 5

I second Graeme Perrow's answer. In some cases where I have something like

bool someCondition = ( hereIsOneLongCondition &&
                       hereIsAnotherOne &&
                       hereIsYetAnother &&
                       ohNoHereIsMore);

I tend instead put the expression in a function:

bool someCondition = Foo();

which has the benefit of being able to allow Foo() to be edited more easily - I can comment individual lines:

bool Foo()
{

   bool result = true;

   if (!hereIsOneLongCondition)
   {
      result = false;
   }

   if (!hereIsAnotherOne)
   {
      // this was added to fix such-and-such bug
      result = false;
   }

   // etc

   return result;
}

Above, I said some since this isn't always possible, and it does produce more lines of code. Spotting bugs and refactoring is easier, though.