code assist would help - or am I the only idiot?

[Daniel Billingsley]

Speaking of trying to read deeply nested if-else blocks...

I often find it's not always easy to tell one indent level from another
(granted I keep my tab settings low so I'm not halfway across the page by
the 3rd level), and I find myself doing things like this to help me keep it
straight:

class MyClass
{
public void SomeMethod()
{
blah blah blah
switch (something)
{
case blah blah blah
} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Mainly so that when I'm working on the code and need to insert functionality
after the switch, for example, it is instantly obvious exactly where that
code goes. As someone pointed out, the "end" keywords of VB do make that a
little more readable, but as those statements don't say "what" is being
ended only so much so.

Does anyone else do this sort of thing, or am I the only one that likes
small tab indents, or just the only idiot that can't read my own code?

If I'm not, then wouldn't this be a nice code assist feature like when you
type "///" in front of a method?

(I know it's not an earth-moving topic, but sometimes something light to
discuss brightens the day a bit, doesn't it?)

 

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

Actually, I think that might be a really good idea. When you place a
closing bracket on certain code elements (and you have the feature turned
on), it would insert the line before the opening bracket (if it is a switch,
if, while, etc, etc). This could have a good impact on code readability.

I'll forward it to someone at MS who will take a look at it (and I will
mention it was your idea as well, and your email).

 

[Mike]

I do that all the time for the same reasons (tab indent at 2 characters,
BTW). It definitely makes it easier to follow nested blocks of code. Using
your sample code, I just drop the "end:" portion:

class MyClass
{
public void SomeMethod()
{
blah blah blah

switch (something)
{
case blah blah blah

} // switch (something)

} // SomeMethod()

} // class MyClass


Also, I typically drop parameters from the comment to keep it simple:

SomeMethod( param1, param2 )
{
blah blah blah

} // SomeMethod()


-Mike

 

[Alan Pretre]

I often find it's not always easy to tell one indent level from another
(granted I keep my tab settings low so I'm not halfway across the page by
the 3rd level), and I find myself doing things like this to help me keep it
straight:
} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Too much noise in the code, just learn and use Ctrl-] to find matching {},
(), [], #region...#endregion, etc.

-- Alan

 

[Jon Skeet [C# MVP]]

} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Too much noise in the code, just learn and use Ctrl-] to find matching {},
(), [], #region...#endregion, etc.

Likewise - it never seems to be a problem for me. Still, I guess that's
what options are for

 

[Daniel Billingsley]

Interesting point of view. I don't see it any more noisy than comments, and
serving the same *general* purpose of readability/understandability. Do you
take the same general point of view on comments (not documentation
comments)? I have kind of mixed feelings about them - sometimes I think if
my code is properly factored and the reader understands the language it
should be pretty self-evident what I'm doing, so a comment like "//
instantiate the DataReader" becomes rather redundant noise to the code
itself.

The Ctrl-] doesn't really help with the issue I'm talking about, and I think
that would be a horribly noisy overuse of #region. Yeah Jon, I guess that's
what options are for.

I wonder if you two run with bigger tab indents, which would negate the
issue.??

} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Too much noise in the code, just learn and use Ctrl-] to find matching {},
(), [], #region...#endregion, etc.

Likewise - it never seems to be a problem for me. Still, I guess that's
what options are for

 

[Daniel Billingsley]

Yeah, that's actually exactly how I do it. I thought the "end" would make
it a little more generally informative, but the closing bracket itself makes
"end" redundant.

 

[Daniel Billingsley]

I'm not sure if we're talking about the same thing. I'm talking about
comments after the closing curly bracket indicating what is being closed,
which is sometimes hard to determine when an indent of 4 doesn't look that
obviously different than an indent of 6 and there's lots of closing brackets
in the neighborhood. What line are you thinking of inserting before the
opening bracket?

Daniel,

Actually, I think that might be a really good idea. When you place a
closing bracket on certain code elements (and you have the feature turned
on), it would insert the line before the opening bracket (if it is a switch,
if, while, etc, etc). This could have a good impact on code readability.

I'll forward it to someone at MS who will take a look at it (and I will
mention it was your idea as well, and your email).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Speaking of trying to read deeply nested if-else blocks...

I often find it's not always easy to tell one indent level from another
(granted I keep my tab settings low so I'm not halfway across the page by
the 3rd level), and I find myself doing things like this to help me keep it
straight:

class MyClass
{
public void SomeMethod()
{
blah blah blah
switch (something)
{
case blah blah blah
} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Mainly so that when I'm working on the code and need to insert functionality
after the switch, for example, it is instantly obvious exactly where that
code goes. As someone pointed out, the "end" keywords of VB do make

that

a
little more readable, but as those statements don't say "what" is being
ended only so much so.

Does anyone else do this sort of thing, or am I the only one that likes
small tab indents, or just the only idiot that can't read my own code?

If I'm not, then wouldn't this be a nice code assist feature like when you
type "///" in front of a method?

(I know it's not an earth-moving topic, but sometimes something light to
discuss brightens the day a bit, doesn't it?)

 

[Daniel Billingsley]

Jon, since this is clearly an IDE issue, but would be peculiar to C# code,
is it OT here or not (by reference)??

 

[Kevin Cline]

Speaking of trying to read deeply nested if-else blocks...

I often find it's not always easy to tell one indent level from another
(granted I keep my tab settings low so I'm not halfway across the page by
the 3rd level), and I find myself doing things like this to help me keep it
straight:

class MyClass
{
public void SomeMethod()
{
blah blah blah
switch (something)
{
case blah blah blah
} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Mainly so that when I'm working on the code and need to insert functionality
after the switch, for example, it is instantly obvious exactly where that
code goes. As someone pointed out, the "end" keywords of VB do make that a
little more readable, but as those statements don't say "what" is being
ended only so much so.

Does anyone else do this sort of thing, or am I the only one that likes
small tab indents, or just the only idiot that can't read my own code?

You are not the only idiot. I used to write methods that spanned pages.
Then I got better. Now instead of:

public void SomeMethod()
{
// perform complicated magic
blah blah blah

switch (something)
{
case blah blah blah
} // end: switch (something)
} // end: SomeMethod()

I write:

public void SomeMethod()
{
PerformComplicatedMagic();
DoSomethingAccordingToSomethingElse();
}

private void DoSomethingAccordingToSomethingElse()
{
switch (something)
{
...
}
}

Or maybe:
public void SomeMethod()
{
PerformComplicatedMagic();
something->take_action( /* this? */ );
}
}

Make this a habit and you'll be amazed how often you end up reusing those
little functions.

 

[Jon Skeet [C# MVP]]

Interesting point of view. I don't see it any more noisy than comments, and
serving the same *general* purpose of readability/understandability. Do you
take the same general point of view on comments (not documentation
comments)? I have kind of mixed feelings about them - sometimes I think if
my code is properly factored and the reader understands the language it
should be pretty self-evident what I'm doing, so a comment like "//
instantiate the DataReader" becomes rather redundant noise to the code
itself.

Exactly. I'm fine with comments which are *useful*, but most of the
time to be honest if methods are short enough, the method itself and
all the fields used are clearly documented, implementation comments
aren't necessary. They're useful to give hints as to why something
looks strange, eg to avoid off-by-one errors, or general progress ("by

The Ctrl-] doesn't really help with the issue I'm talking about, and I think
that would be a horribly noisy overuse of #region. Yeah Jon, I guess that's
what options are for.


I wonder if you two run with bigger tab indents, which would negate the
issue.??

I use a tab of 4 (except for XML where I use a tab of 2).

 

[Alan Pretre]

The Ctrl-] doesn't really help with the issue I'm talking about, and I think
that would be a horribly noisy overuse of #region. Yeah Jon, I guess that's
what options are for.

Well it wouldn't help on printed copy, but I very rarely print out source
code.

I wonder if you two run with bigger tab indents, which would negate the
issue.??

Std. 4, used to use 3 years ago but came over to the dark side ;-)


Back when I was in college years ago we learned "pure" structured Pascal.
One of the drawbacks of pure structuring is very deep nesting of your code.
Over the years I've started to use more break's, continue's, return's, and
elseif's to reduce nesting. It's amazing what a difference it makes in
readability.

-- Alan

 

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

It would insert nothing before the first curly bracket, but rather it
would take the line before the opening curly bracket and insert it after the
closing curly bracket.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I'm not sure if we're talking about the same thing. I'm talking about
comments after the closing curly bracket indicating what is being closed,
which is sometimes hard to determine when an indent of 4 doesn't look that
obviously different than an indent of 6 and there's lots of closing brackets
in the neighborhood. What line are you thinking of inserting before the
opening bracket?

message news:u1%[email protected]...

Daniel,

Actually, I think that might be a really good idea. When you place a
closing bracket on certain code elements (and you have the feature turned
on), it would insert the line before the opening bracket (if it is a switch,
if, while, etc, etc). This could have a good impact on code readability.

I'll forward it to someone at MS who will take a look at it (and I will
mention it was your idea as well, and your email).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Speaking of trying to read deeply nested if-else blocks...

I often find it's not always easy to tell one indent level from another
(granted I keep my tab settings low so I'm not halfway across the page by
the 3rd level), and I find myself doing things like this to help me

keep
it

straight:

class MyClass
{
public void SomeMethod()
{
blah blah blah
switch (something)
{
case blah blah blah
} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Mainly so that when I'm working on the code and need to insert functionality
after the switch, for example, it is instantly obvious exactly where that
code goes. As someone pointed out, the "end" keywords of VB do make

that

a
little more readable, but as those statements don't say "what" is being
ended only so much so.

Does anyone else do this sort of thing, or am I the only one that likes
small tab indents, or just the only idiot that can't read my own code?

If I'm not, then wouldn't this be a nice code assist feature like when you
type "///" in front of a method?

(I know it's not an earth-moving topic, but sometimes something light to
discuss brightens the day a bit, doesn't it?)

 

[Daniel Billingsley]

Ah, ok.. I misunderstood your statement "it would insert the line before the
opening bracket". We're indeed on the same page.

Daniel,

It would insert nothing before the first curly bracket, but rather it
would take the line before the opening curly bracket and insert it after the
closing curly bracket.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I'm not sure if we're talking about the same thing. I'm talking about
comments after the closing curly bracket indicating what is being closed,
which is sometimes hard to determine when an indent of 4 doesn't look that
obviously different than an indent of 6 and there's lots of closing brackets
in the neighborhood. What line are you thinking of inserting before the
opening bracket?

message news:u1%[email protected]...

place

a

closing bracket on certain code elements (and you have the feature turned
on), it would insert the line before the opening bracket (if it is a switch,
if, while, etc, etc). This could have a good impact on code readability.

I'll forward it to someone at MS who will take a look at it (and I will
mention it was your idea as well, and your email).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Speaking of trying to read deeply nested if-else blocks...

I often find it's not always easy to tell one indent level from another
(granted I keep my tab settings low so I'm not halfway across the

page
by

the 3rd level), and I find myself doing things like this to help me keep
it
straight:

class MyClass
{
public void SomeMethod()
{
blah blah blah
switch (something)
{
case blah blah blah
} // end: switch (something)
} // end: SomeMethod()
} // end: class MyClass

Mainly so that when I'm working on the code and need to insert
functionality
after the switch, for example, it is instantly obvious exactly where that
code goes. As someone pointed out, the "end" keywords of VB do make that
a
little more readable, but as those statements don't say "what" is being
ended only so much so.

Does anyone else do this sort of thing, or am I the only one that likes
small tab indents, or just the only idiot that can't read my own code?

If I'm not, then wouldn't this be a nice code assist feature like

when
you

type "///" in front of a method?

(I know it's not an earth-moving topic, but sometimes something

light

to

 

[Daniel Billingsley]

You're right, but I'm not talking about a "little function", I'm just
talking about a block of code. Surely you don't write a new method every
time you need if statements or switches nested a few levels deep.

 

[Daniel Billingsley]

No, you're right.

There doesn't appear to be a "pretty printer" for C# and I'm tossing around
the idea of writing my own.

The Ctrl-] doesn't really help with the issue I'm talking about, and I think
that would be a horribly noisy overuse of #region. Yeah Jon, I guess that's
what options are for.

Well it wouldn't help on printed copy, but I very rarely print out source
code.