Acceptable to have spaces before dot?

What is the general opinion on the 2nd indentation method below.

// Normal indentation
a.Value        = "foobar";
ab.Checked     = false;
foo.Value      = "foobar";
foobar.Checked = true;

// Spaces before the dot to align the properties/methods
a     .Value   = "foobar";
ab    .Checked = false;
foo   .Value   = "foobar";
foobar.Checked = true;

This should probably be a wiki, but I either don't have enough privileges or don't know how to change it.

edit

I've decided to add another example to better show where such an indentation style might be useful.

fooA   .开发者_JAVA技巧PropertyA = true;
foobarB.PropertyA = true;

Changing PropertyA on all lines would be much easier with the new multi-line editing feature in VS2010.

Also having whitespace, and even line-breaks before the dot is not uncommon at all in C# (see LINQ).

Spaces before the dot? Dear God no!

I would never use either personally. I would use just traditional formatting, eg:

a.Value = "foobar";
ab.Checked = false;
foo.Value = "foobar";
foobar.Checked = true;

I understand this may not be as pleasing to the eye, but feel the others are less ideal.
Reasons being:-

1. Harder to maintain: Sometimes you may have smaller or larger variable names, or introduce other variables in your code which means you have to adjust formatting of all entries.
2. Automatic formatting might mess this up: If you use ReSharper (possibly with standard VS?) when pressing ; the formatting will adjust it back into line anyway, so you have to go out of your way to ensure it wouldn't do this.
3. I can't think of one right now, but I can't handle only having two points.

Edit! Thought of another point. There are more tricky keystrokes involved: For instance, for me with ReSharper to achieve the latter formatting I would type foo, enter/tab (to confirm auto-complete), tab times X amount of tabs required up to variable length (annoying), ., Value, tab to confirm auto-complete again, = then assigning data then ; and then yell at Visual Studio because all my non-standard formatting was undone as I expressed in point 2, so finally a press of CTRL+z would restore back the formatting we just had. :)

I've always used "Normal indentation." The other way seems less clear to me because I am not expecting to see indentation of that nature.

I would use spaces before the dot only if it's all the same property/method. If it's a mix of properties, like you have in your example, I'd stick with 'Normal'.

However, I think it's a moot point, because the Visual Studio autoformatter will collapse everything next time someone types a } to close any enclosing block.

Acceptable from C# language point of view.

First style is easier for me to read compared to second. I think it is because spaces before dot look very strange - in most written languages there is no space before dot.

I personally don't fight with VS IDE. Default style is fine with me.

Note that using proportional fonts totally breaks such formatting (using such fonts is extremly unusual for editing code, but ask around).

Edit: using space (+new line) for fluent interfaces looks good ( http://en.wikipedia.org/wiki/Fluent_interface#C.23).

I tried it a couple of time. Never was happy with out it looked afterwords.

I always thought aligning on the 'dot' might work in the right context:

// -----------------------
// decimal-style alignment
// -----------------------
     a.Value   = "foobar" ;
    ab.Checked = false    ;
   foo.Value   = "foobar" ;
foobar.Checked = true     ;

But you lose the clean left margin that leads the eye down the page and maintains your sense of indent level. So you're back to keeping the dot with the identifiers it connects. However...

Aligning the equal signs is good practice as it helps order the whole set:

// -----------------------
// tabular coding
// -----------------------
a.Value        = "foobar" ;
ab.Checked     = false    ;
foo.Value      = "foobar" ;
foobar.Checked = true     ;

The more order one imposes on one's code the more likely one is to notice things that are out of whack.

The parser doesn't care about tidy, readable code, but the compiler isn't the target audience for your code. Your target audience is other human beings that have to read it and comprehend it. In particular the poor schmuck — who might be you! — that has to pick up the code in a hurry and fix it 3 or 5 years from now, without no documentation to aid in understanding.

The spaces before the dots I would NEVER do, simply because as I am reading code I stop looking for a dot as soon as I see a space. The spaces after the dot, I HAVE done in the past, but hardly ever and I really prefer not to use it. The problem with using a style like that is that even if it is more readable to you, if you take such a large leap (meaning the spaces before the dot) from what might be considered a "norm" then you are going to hinder more people than help. Sticking with the standard in your team or workplace is the most important thing. Even if it is not a black and white standard, if the other 99 developers at your company us VS standard and you put all the spacing before your dots it is not going to improve anything.