views:

233

answers:

5

When it comes to using statements in C# (not to be confused with using directives that import namespaces), Visual Studio doesn't indent single-line code that follows if no braces are employed. This is typical of "nesting" using statements as shown in this SO question.

I find it confusing that subsequent statements after using are not indented, unlike the formatting of an if statement:

// non-indented using statement
using (var myResource = new SomeIDisposableResource())
myResource.Indent(false);

// indented if statement
if (something == true)
    IndentMe();

Is there any reason not to indent, or is it just preference?

// indented using statement, but not the default VS formatting
using (var myResource = new SomeIDisposableResource())
    myResource.Indent();

EDIT:

Further testing reveals that I was incorrect about some of the VS formatting behavior. If you type a using statement:

using (var myResource = SomeIDisposableResource())

...and hit enter, the cursor will align with using. If the next line is also a using statement, it will continue to align. If it is not, VS will indent it upon completion. Thus my original question is somewhat invalidated, because my first example is not really achievable unless you override the default formatting or use an IDE that doesn't do that.

Still, it is worth knowing that multiple using statements are best treated as a single block because they technically are. The lack of indentation only applies when the statements are sequential using statements without braces; and as one gets used to it, they stop looking so unusual.

As always thanks to all those who answered for the insight and experience in even these minor programming details.

+12  A: 

It's preference. I always indent, and place the necessary items in brackets

using(var t = new t())
{
   t.Foo();
}
Kevin
Even for single lines? I presume the braces then just force VS to indent according to your preference?
JYelton
+1 even for single lines.
sixlettervariables
Yes, I even put it for single lines. It's preference, but I have run into too many situations where someone accidentally comments or deletes something and an if statement extends it's control beyond where it should. Sometimes its a massive headache that causes hours of debugging. I follow the explicitly clear and better safe than sorry principle.
Kevin
@Kevin: Makes sense, thanks for the insight.
JYelton
Kevin, were any of these situations in C# as opposed to C++ or C?
Steven Sudit
@JYelton: Keep in mind that VS will indent regardless of the braces.
Steven Sudit
@Steven, actually yes. When I have had this happen in C# it is generally, because the code is bad to begin with. It's confusing, and sometimes poorly done. For a long time, I never thought this would make that much of a difference in a language like C# (compared to C++, C) it is a lot easier to understand. And then i saw the C# code where it happened. I was unbelievably frustrated when I figured out that was the problem.
Kevin
@Kevin: Do you Format Document as part of your review process?
Steven Sudit
With the team I'm on now, yes we do. This was on a different project where there was no code review process or real standards either (really no one wanted to look at that code more than they had to.)
Kevin
@Kevin: That's kind of what I figured. When you have no standards and no review process, nothing works because nothing is enforced.
Steven Sudit
@Steven Sudit: What I failed to do was complete the statement I was writing with a semicolon to see that it would automatically indent. I was working off the position of the cursor upon hitting enter. The behavior is different in the IDE writing a using statement versus an if statement. I amended the question to reflect this. Apparently I need to ensure that I've allowed auto-formatting to do its work before I assume anything! :)
JYelton
@JYelton: You're right: with `if`, it indents as soon as you hit enter. I'm guessing the reason it doesn't do this for `using` is precisely so you can stack them up as Jon did.
Steven Sudit
+5  A: 

Easy fix: always use explicit blocks, even for single lines. Visual Studio will then properly indent, and as a bonus your code will be more maintainable!

Randolpho
Do you mean more maintainable because braces affect variable scope?
JYelton
@JYelton, not quite. More maintainable because if you later want to add a line there or remove it for debugging or something, the braces are already there, and you don't risk forgetting them and wasting hours debugging it.
Martinho Fernandes
@Martinho Fernandes: I've had such situations occur; definitely a good reason to always use braces.
JYelton
It's impossible to forget them unless you're using Notepad or something. The VS editor prevents this error.
Steven Sudit
+21  A: 

As others have said, always use braces. However, there's one idiom which somewhat goes against this and uses the "non-indentation":

using (Resource1 res1 = new Resource1())
using (Resource2 res2 = new Resource2())
using (Resource3 res3 = new Resource3())
{
    // Do stuff with res1, res2 and res3
}

But I'd always use braces for the innermost block :)

Jon Skeet
Good call, I forgot about multiple using statements on top of each other.
Kevin
The stack of using statements seems to go against my model of code dependencies. By that, I mean that I view indented code as being dependent on the preceding block with one less indent. Inserting some code between the using statements would seem okay based solely on formatting, but unless I am wrong, it would break the association between the statements. I guess this is just one of the occasional exceptions to the rule?
JYelton
If you're inserting code between two lines, presumably you're looking at those lines.
recursive
@JYelton: Yes, it's an exception - I rarely find myself doing it anyway, to be honest, but it's useful to know about. Basically I mentally treat all the using statements as a block of them.
Jon Skeet
If we're going to allow stacking, then I'm not sure why we need the braces.
Steven Sudit
@Steven: I'm effectively treating all the using statements as one... I still want the braces to show the body of code to be executed.
Jon Skeet
The reason I used to use braces for this sort of thing in C++ is that it was all too easy to have two indented statements, so it looked like both would be in the block. In C# using VS as my editor, I can't do that accidentally, or even intentionally. It keeps correcting my error! This removes any motivation to use braces.
Steven Sudit
I posted my comment as an answer, so I could show samples. Feel free to downvote it. :-)
Steven Sudit
@recursive: Oh you're right, I don't have a need to insert code between them, but I can see a case where someone might erroneously try to. I just wanted to firm up on the matter. :)
JYelton
A: 

Like my C instructor told me over 10 years ago: Always, always, always use the braces. Odds are good someone is going to come along (possibly even you) and throw in another line of code, then wonder why it's not behaving correctly.

monkeymindllc
Yes, a good rule for C, yet it doesn't apply to C#.
Steven Sudit
Really? It's served me well since c# first came out. Why would you say it doesn't apply?
monkeymindllc
A: 

I like being downvoted when I'm wrong, so I'm going to make an answer out of this...

Here's how I would format it:

using (Resource1 res1 = new Resource1())
using (Resource2 res2 = new Resource2())
using (Resource3 res3 = new Resource3())
  DoStuffWithResources(res1, res2, res3);

If I were to replace DoStuffWithResources with multiple statements, I would make use braces. However, my editor prevents me from ever making the following mistake:

using (Resource1 res1 = new Resource1())
using (Resource2 res2 = new Resource2())
using (Resource3 res3 = new Resource3())
  DoStuffWithResources(res1, res2, res3);
  DoOtherStuffWithResources(res1, res2, res3);

When I try to enter the above, I immediately get:

using (Resource1 res1 = new Resource1())
using (Resource2 res2 = new Resource2())
using (Resource3 res3 = new Resource3())
  DoStuffWithResources(res1, res2, res3);
DoOtherStuffWithResources(res1, res2, res3);

Pro tip: A downvote is not a counterargument, so if you don't have one, you shouldn't be voting.

Steven Sudit
My argument for using braces isn't because of what *I might do*, it is the next person that comes in that I do not trust. Much like driving on a snowy road in winter - I know that I can take care of myself, it is everyone else driving that scares the living hell out of me. Point given, you will recognize that the second isn't indented - but how about the Jr. that gets brought in to do defect work?
joseph.ferris
The next person is also using the VS editor, so the same thing prevents *them* from accidentally creating that second code block. If you're in a typical shop, code will be reviewed prior to being released or put into production. As part of code review, I always Format Document to ensure that nothing changes.
Steven Sudit
@Steven, code will be reviewed? I wish! If only the LOB saw such matters as clearly as programmers do.
Anthony Pegram
@Anthony: It's actually fine if you downvoted -- you're allowed to be wrong. All I ask is that people offer a counterargument as opposed to a thumb. Your argument seems to be that some shops don't do code reviews. Sadly, you're right that these exist. However, you're also right in your implication that they suffer for this. Not much point talking about the benefits of one formatting over another if, in the end, you can get away with murder.
Steven Sudit
It turned out that I *did* downvote but didn't mean to. But on code reviews, I'm doing work on a team for a rather large financial company. The LOB is paying for enhancements. We (meaning the grunts) all agree that code reviews would be nice. Refactoring obscenely long methods would be wonderful. (And I do mean *obscenely* long.) It would be so much better for the LOB in the long run. They don't care about the long run, they care about the next release. But don't mind me, I'm basically just venting now.
Anthony Pegram
@Anthony: We've all been there. Some of us are there now, the rest of us will be there again sooner or later. Vent if you must; it's slightly better than exploding, though not nearly as good as finding a better job. :-)
Steven Sudit
@joseph.ferris: I replied to your comment but forgot to prefix it.
Steven Sudit