# Aligning '=' on protocol buffers .proto files [closed]

Should the equals sign be alined on protocol buffers? I am having a huge discussion with a colleague and we can't get to decide on what's the best practice.

message foobar {
optional bool var_one_short             = 1;
optional bool var_two_looooooooong_name = 2;
optional bool another_var               = 3;
}


vs

message foobar {
optional bool var_one_short = 1;
optional bool var_two_looooooooong_name = 2;
optional bool another_var = 3;
}

-

## closed as off-topic by Jerry Coffin, Jamal♦Jul 2 at 14:00

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Questions must involve real code that you own or maintain. Questions seeking an explanation of someone else's code are off-topic. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.

This question appears to be off-topic because it is about formatting data, not code (although code can be generated from a .proto file, the .proto file itself doesn't contain any code). –  Jerry Coffin Jul 2 at 13:39
@JerryCoffin I had completely forgot about this question if it wasn't for the notification. This question was originally migrated from SO to here. I don't want to seem protective but I actually disagree, protobufs defines a schema, so I would argue that schemas are subject to codereview. –  fmsf Jul 2 at 14:19
You raise a fair argument, but the long and short of it is that you need to draw a line somewhere. IMO, the line is drawn at languages that let you specify actions to be taken. Yes, actions such as reading and writing are implied with protobufs, but they're still strictly implicit, not embodied in the code itself. –  Jerry Coffin Jul 2 at 14:29

I think the second version is much easier to maintain. If you have a new variable with a longer name (like var_two_reaalllllly_looooooooong_name) you don't have to modify three other lines too to keep it nice. The first version also could cause unnecessary patch/merge conflicts.

From Code Complete, 2nd Edition by Steve McConnell, p758:

Do not align right sides of assignment statements

[...]

With the benefit of 10 years’ hindsight, I have found that, while this indentation style might look attractive, it becomes a headache to maintain the alignment of the equals signs as variable names change and code is run through tools that substitute tabs for spaces and spaces for tabs. It is also hard to maintain as lines are moved among different parts of the program that have different levels of indentation.

-
I think it's important to note that a lot of modern editors support this (example: Sublime Text 2), so maintenance becomes trivial. –  seand Feb 28 '13 at 16:19
I use sublime and yes it makes it easier. But his opinion convinced me. –  fmsf Feb 28 '13 at 16:21

This is a simple "Readability vs Maintainability" issue. In a case like this, choose the second one. So, if you change your code or add a new variable, you don't have to realign the code at the end. You can achieve readability with other ways like giving your variables good names.

-

I like more the first solution because it visually groups together the variables on the left side of the = and the value on the right side. Unfortunately I can't back this preference with a strong reason other than personal taste.

In your situation I'd struggle for uniformity across your codebase and define a single convention that every programmer should follow. It seems that you and your colleague are already trying to agree, but I wanted to point it out explicitly because I think that it is very important.

-