all groups > visual studio .net ide > march 2007 >
You're in the

visual studio .net ide

group:

C# IDE - commenting / uncommenting problems



C# IDE - commenting / uncommenting problems Zytan
3/29/2007 5:45:16 AM
visual studio .net ide: Ctrl+E, C and Ctrl+E, U will comment and uncomment out multiple lines
(there's buttons in the Text Editor toolbar for this). It has two
issues:

1. It will not include the // for empty lines, which makes it hard to
visualize a single commented group. Since programmers very often use
spaces to improve readability, this happens often, and it has the
exact negative effect when you use it (destroying readability).

2. If you use tabs, it converts them into spaces. It will restore
then when you uncomment with the shortcut (or button), but, if you
uncomment manually (say, for just a few lines) you're stuck with
spaces. That's where those damn spaces are coming from, which are
annoying to cursor through. 4x as slow, in fact, and unintuitive.

Is there any solution to these issues?

Zytan
Re: C# IDE - commenting / uncommenting problems Zytan
3/29/2007 1:24:08 PM
[quoted text, click to view]

This is not a solution. It solves a minor problem and introduces a
much larger one: the loss of the usefulness of tabs.

[quoted text, click to view]

I thought 4 was the standard in IDEs. I know it's annoying in notepad
or whatever, but any editor without color coding is annoying, so
there's other issues with them than just tabs, so I don't use them,
ever. Maybe people change the setting in VS, but I generally leave
settings as is so that are normal. But, it's a valid point if you're
dealing with multiple editors with different settings. I never have.

[quoted text, click to view]

I hope I never run into a machine so old that it doesn't handle tabs.
A valid point for those of us on older systems. Do such people even
exist?

[quoted text, click to view]

Yeah, could get messy, I agree. Luckily my files will always be made
and edited within VS. If not, I will hope that the IDE at least
adheres to the standards VS has set (kept?) over the past decade.

[quoted text, click to view]

But, I have never had any of the issues you have raised. If I get rid
of tabs, I lose the benefits from them, and gain nothing.

[quoted text, click to view]

Tabs aren't used to saved bytes. They are used to save time. It is
amazing to me that anyone uses spaces in their IDE. I cannot fathom
dealing with the frustration of how long it takes to merely move the
cursor through spaces. (The only solution is to use Ctrl + arrow
keys, and for people who use that (I don't), I guess tabs or spaces
are fine, either way, so yeah, go with spaces). Tabs also just seem
proper. It's a distinct indentation. Spaces are just a guess.
People could use any number of them. It's unfortunate that a proper
tab size isn't standardized, but i think it is within (recent) IDEs.

The only other solution is if the IDE automatically acts as though the
tabs actually exist, even though they are stored as spaces. VS
doesn't do this.

Zytan
Re: C# IDE - commenting / uncommenting problems Chris Nahr
3/29/2007 5:24:00 PM
[quoted text, click to view]

I don't know about the other issue but the solution for this is very
simple: don't use tabs, ever.

Tabs are notoriously prone to formatting breakage because everyone has
different tab settings, so what shows up neatly aligned in one editor
is a jumbled mess on another. Some text display or processing tools
might not handle tabs at all, or might not allow you to specify the
correct tab expansion settings. Then you have the issue of comparison
mismatches between visually identical files in diff and SCCS utilities
because tabs got replaced with spaces or vice versa.

Just don't use tabs. Let all your editors automatically convert tabs
to spaces on input, and you'll never have these issues again. Tabs
were good for saving a few bytes on a 1960s mini-computer. They have
absolutely no purpose today and should never be stored in text files.
--
Re: C# IDE - commenting / uncommenting problems Chris Nahr
3/30/2007 12:00:00 AM
[quoted text, click to view]

Precisely. Of course you don't move through spaces just with the
arrow keys -- that's what all those powerful cursor movement commands
are for! Besides, Visual Studio usually auto-positions the cursor at
the first non-blank character anyway, so it's not that often that you
have to move through spaces at all. Certainly not an issue for me.

[quoted text, click to view]

Now that's just nonsense. People could also use any number of tabs --
someone might want to indent with the usual 8 spaces per tab, and when
an IDE has 4 spaces per tab he'd use two tabs per indentation. Or
maybe four tabs if the IDE is set to XML/HTML mode with 2 spaces/tab!

Also, people could use any number of spaces per tab. I take it you've
never seen those C# code formatting guidelines where someone seriously
recommended three spaces per indendation level? What about XML and
HTML files which are usually indented with two spaces? Are you going
to alternate between tabs and spaces for each level, or are you going
to change the number of spaces per tab between file types?

And if you wonder why I'm bringing this up -- think ASP.NET and XAML.
That's a mix of HTML and XML, respectively, with embedded C# code. Are
you going to switch tab sizes in the middle of a file, depending on
the cursor position?

[quoted text, click to view]

You are quite wrong about that. Tab sizes differ between file types,
and programmers will change tab sizes anyway if they don't like them.
There's no such thing as a tab standardization.
--
Re: C# IDE - commenting / uncommenting problems Zytan
3/30/2007 10:51:47 AM
[quoted text, click to view]

You should need unusual shortcuts to make an issue not an issue. Just
solve the issue, and then it works for people who don't use the
unusual shortcuts, as well.

It is an issue for me. One example is when I uncomment text, as I've
explained. The text is just 4 spaces away. Do you use Ctrl+right
arrow? or press right arrow once? I use right arrow. I bet people
who use Ctrl+arrows would do the same. Then, they are going through
spaces. It's annoying, and it does bite people. With tabs, there are
no such issues.

[quoted text, click to view]

Not nonsense. I highly doubt any single person on this planet uses
more than 1 tab for indentation. We all consistently use 1. If not
all, the extreme vast majority. It's the old decrepit editors that
make it bad but not adhering to any standard for how large to make
them. On the other hand, look at spaces... 2, 3, 4, 5, 8, and who
knows how many others? Completely inconsistent.

[quoted text, click to view]

I'm talking about source code. Not XML or HTML. Source code. All
source code. One tab.

Only when using spaces do you have the issue of dealing with how many
you should use. I understand why people use them, to avoid issues
between multiple editors, but for a lot of people, they don't deal
with such things. I'm not writing code to be put on a webpage. I'm
writing in VS. Fortunately, I needn't worry about using spaces
because of people using anticated editors, so I use tabs, and all of
these space issues vanish. (Except when VS puts spaces in when I
asked it not to, which is my sole concern today.)

[quoted text, click to view]

Again, I am talking about programming in an IDE, not publishing code.
Yes, I am fortunate to not have to worry about those issues. If I
did, then I'd probably try and use a consistent standard with them.
Unfortunately, that breaks down the benefits of tabs, for a better
benefit. Since, I just use my IDE, I am not going to use a worse idea
(and require Ctrl+arrow to move through 4 spces when i could use arrow
once) just because other people are unfortunately needing to embed
code meant to be written in an IDE into something else because they
wish to share it.

I agree spaces are best for portability. But, that's not an issue for
most people. I would suggest such displays of code outside of the
editor be improved anyway. They should covert tabs into spaces as
needed when it is pasted it. (When people copy and paste it back into
their own IDEs, it'd convert it back to tabs.) Look at the number of
webpages showing monochromatic code. They should have coloring. They
are just an incomplete solution to a problem, but the best available
so far, so people try to ease the issues uses spaces, making their IDE
editing worse in the process. I feel for them.

[quoted text, click to view]

I think the de facto is 4. I'd be surprised if any major IDE uses
otherwise. And even if that were the case, I'd love to see the
%ages. I bet 99%+ use 4. If that's not de facto, I don't know what
would be. Besides, the number of spaces can be changed, as you said,
to suit the programmer. I could use a different font, and increase it
to 6 or 7 since the space is smaller than in courier. With tabs, none
of this is an issue, since the code on another IDE that uses tabs is
displayed in the same format.

Spaces are only for portability for decrepit systems, or systems not
meant to display code. I feel for people who need to use them.
Luckily, I don't. Let's move ahead instead of being held back:
http://nickgravgaard.com/elastictabstops/
(amazingly great read)
Otherwise, we'll never improve.

Zytan
AddThis Social Bookmark Button