|
Nick Gravgaard improved the idea of TabStop in the code; He developed the Elastic TabStops.
I really liked this. Visual Studio 2010 should have this option.
See an example on this site:
http://nickgravgaard.com/elastictabstops/[^]
modified on Saturday, June 26, 2010 4:27 PM
|
|
|
|
|
At least you could give a warning that site tries to silently install malware... actually java plug-in but it isn't a big difference.
|
|
|
|
|
Used "View source" and there is nothing strange ...
MSE and McAfee didn't report a problem.
Maybe the malware was removed meanwhile?
|
|
|
|
|
Nice idea 
But the drawback is that if you have to read code in another editor which does not support these elastic tabstops the code may look awful? Or are there spaces everywhere for other editors not supporting elastic tabstops?
For .NET code (C#) I prefer using StyleCop (using tabs!!) in order to produce consistent and "beautiful" code 
|
|
|
|
|
This would be a non-issue if
1. source revision control stored the parse tree, instead of the raw text file, and
2. there were rules in your source revision control that would give you a raw text file on get of source that formatted it according to your desire.
This also would make merging much easier as the parse trees would be compared, rather than the raw text.
|
|
|
|
|
|
I WILL! I WILL! Got a million bucks?
No? Ooooh, what's that shiny thingie over there...
|
|
|
|
|
Most developers become used to using the editor of their choice. Forcing a single editor for all to use seems harsh since most developers need to adapt to the coding style where they work. As different editors expand tabs differently, legacy code takes on a bizarre appearance if tab characters are inconsistently used if a given file.
For example, the inconsistent use of tab characters has encouraged several types of software defects.
Consider the following;
(previous_code);
if (some_condition)
(do_this);
(do_this_too);
(subsequent_code);
Was the author's intent that do_this_too only be executed if some_condition was true? No way to tell from here. Obviously, that is not how the code gets executed and this could caused by a single tab setting (spaces per tab) being set differently than the original author's setting.
Obviously braces should be required to avoid this confusion.
This is only one of several cases caused by allowing tabs in source code.
|
|
|
|
|
Here is the correct code snippet. (ignore spaces (.) and tabs (t))
(....)(previous_code);
(....)if (some_condition)
(........)(do_this);
(tttttttt)(do_this_too);
(....)(subsequent_code);
(....) is 4 spaces.
(tttttttt) is a single tab expanded to 8 spaces.
|
|
|
|
|
You should consider to be more consistent? 
Use spaces or tabs but not both!
For legacy code: <Ctrl+K, Ctrl+D> which reformats the code using the current VS settings.
|
|
|
|
|
|
|
Yes and no.
I prefer tabs (tabsize = 2) which makes collective code ownership easier because there are codes prefering tabsize = 4;
The given sample at StackOverflow using multiple spaces within the code (not for indention). You shouldn't to it that way. It was good for C++ but for C# you should avoid it:
StyleCop + NerdBank custom rules will be your friends
|
|
|
|
|
hfrmobile wrote: You shouldn't to it that way.
Why?
hfrmobile wrote: It was good for C++ but for C# you should avoid it:
Where's the difference?
No, really, these are honest questions.
(I generally would prefer elastic tabstops anyway)
|
|
|
|
|
Sorry for the confusion!
peterchen wrote: Why?
StyleCop: SA1025: The code contains multiple spaces in a row. Only one space is needed.
There is no need for it in C# (for C/C++ it is OK):
public enum PublicEnumeration
{
TestValueNull = 0,
TestValueOne = 1,
TestValueTwo = 2
}
prefer:
public enum PublicEnumeration
{
TestValueNull = 0,
TestValueOne = 1,
TestValueTwo = 2
}
peterchen wrote: Where's the difference?
C# and C/C++ are complete different languages .... OK, they have similar Syntax and keywords, but they're complete different! 
|
|
|
|
|
For the second thing, It's more the comment style that makes a difference - though that's not a bad reason.
If you use another documenting utility, it might be an issue again. "Completely Different languages" doesn't cut it (for the questions I posed)
(I'd say XML comments are the default if you wouldn't have to balance source code readability against documentation quality so much, and if Sandcastle wouldn't be such a sluggish heavyweight.)
hfrmobile wrote: StyleCop: SA1025:
Well... what would you say about
StyleCopEX: SAX1026: newlines detected in method. Entire method can be implemented without newlines.
(i.a.W. a StyleCop warning is not a reason)
|
|
|
|
|
This soft tab may be better. Hard tab sometimes cause inconsistent tabbing as the user do not see extra tabs in the source code in Visual Studio.
Copying the entire code and paste in Microsoft Word and sometimes the extra tab can be seen.
So.... soft tab is better... as it can lesson the formatting as seen on Microsoft Word.
|
|
|
|
|
The ability to copy into MS Word is a poor excuse for a coding guideline. If you really must copy into MS Word, then untabify your code (there's a menu item for it, which you can even map to a key if you use it often) and then copy it.
By the way, I'm not saying that tabs is better. There are other better reasons for using spaces -- copying into MS Word is just a poor one. There are also very good reasons for using tabs, which is why I believe the programming world is so split on the issue.
|
|
|
|
|
Now that I've got a second thought... hard tab seems better now.
I had soft tabs on my code. I then just learned something... I switched to hard tab, then go to the very bottom of the code, then removed the very last closing bracket. I reinserted the closing bracket and all of the spaces were replaced with hard tabs, removing any inconsistent tabbing automatically. Ahh there we go!
|
|
|
|
|
I prefer hard-tabs and not soft-tabs (spaces) because to support coders preferences: Some prefer 4 chars for indention, others prefer just 2 ...
Collective code ownership is easier to mange indenting using tabs and so each coder can use the tab size she/he prefers
Tabs also enables us easier and faster navigation through the code using cursor keys
|
|
|
|
|
To have it consistent we are using in our group AStyle (artistic style) with an common agreed setting, also as a tool within VS.
This allows also the control of spaces between operators and much more.
|
|
|
|
|
|
no, I am mean the artistic style program, you can find it at http://astyle.sourceforge.net
|
|
|
|
|
It's nice to see that they support OpenVMS. That's where I've had trouble in the past. At one company we had a written standard of four SPACEs, and it was good. Then those Visual Studio people came along and didn't follow directions; they were supposed to set VS appropriately, but didn't. I'd open a file on my dumb terminus (or emulator) and the indenting would be screwed up. I wrote my own filter to correct it.
|
|
|
|
|
It is easy to use. Just a Hard Tab press. And also it makes the formatting proper. Pressing a single key instead of several space strokes is always a better idea.
Don't forget to Click on [Vote] and [Good Answer] on the posts that helped you.
Regards - Kunal Chowdhury | Software Developer | Chennai | India | My Blog | My Tweets | Silverlight Tutorial
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
