|
|
Among the useful messages Source Analysis for C# reports I see many instances of:
Tabs are not allowed. Use spaces instead.
I understand this tool is very rigid, as is the entire point of normalizing code, but what is so horrible about tabs? If they're so rotten, why does Visual Studio default to tabs when I hit the enter key? I've seen this item in the class design guide for developers for years - it never made any sense to me but I also never had a tool complain to me about it :)
Can you give me a good reason why I should switch to spaces or let me know how to change the tool?
Thanks!
...I'm going two-for-one here to break in the new discussion board...
|
|
|
|
|
I can't say why tabs are bad, but if you do a "format document" (ctrl-E,D) VS will fix it for you.
|
|
|
|
|
VS can be set up to use tabs as spaces. Some of the default profiles has this set, some have not. If yours is inserting tabs, the in the VS menu go to Tools->Options, find the Text Editor and then expand the C# node, and there you find a setting for tabs. On that page, make sure it is set to insert spaces.
I would recommend turning on the setting.
|
|
|
|
|
Tabs or Spaces, you pick.
I used spaces for 17 years (and I preferred spaces) but tabs for the last 3 (and now I prefer tabs).
Disable "Spacing Rule" SA1027 if you use tabs.
There will probably be a way to add your own rule like "Indentation cannot contain spaces."
|
|
|
|
|
Tabs are bad for a simple reason: different tools will have different settings for the number of spaces per tab. Then, when tab-based and space-based indenting is mixed, which invariably happens for any non-trivial program, the indenting doesn't render correctly when different tools or different have different settings for number of spaces per tab. I have seen this problem a million times in my career.
|
|
|
|
|
Your 'simple' point, that tools can display tab spacing differently, is a great reason why tabs are great.
Your second point is that tabs are bad because some people use spaces?
(And yet, somehow, spaces are not bad because some people use tabs?)
|
|
|
|
|
Yes, that's exactly right. The problem is not spaces, and it is not tabs; it is that both options exist and they don't mix well. Therefore, a team should decide to always use tabs or always use spaces. I believe that using spaces is better because the source code always looks the same regardless of the tool displaying it, since the spaces per tab setting becomes irrelevant.
|
|
|
Edited May 25 2008 at 7:50 PM
|
TAZ wrote:
Tabs are bad for a simple reason: different tools will have different settings for the number of spaces per tab. Then, when tab-based and space-based indenting is mixed, which invariably happens for any non-trivial program, the indenting doesn't render correctly when different tools or different have different settings for number of spaces per tab. I have seen this problem a million times in my career.
And that's a good thing. If one person likes the equivalent of a 4-space indent then she can set their indent to 4 spaces. You can't do that if you always use spaces. If you use multiple computers with different resolutions using tabs makes it easier to be able to fit code within the horizontal limits of your screen. Using spaces means I can't view code differently in different circumstances (without picking another font) because spaces are fixed width. I would disable SA1027.
|
|
|
|
|
I don't want to disable this rule, I want it to conform to my coding standards!
Why doesn't style cop take a look at visual studio settings to figure out whether I prefer tabs or spaces? Settings can easily be enforced across an enterprise using the team settings feature.
|
|
|
|
|
serega wrote:
I don't want to disable this rule, I want it to conform to my coding standards!
Why doesn't style cop take a look at visual studio settings to figure out whether I prefer tabs or spaces? Settings can easily be enforced across an enterprise using the team settings feature.
StyleCop is not about configuring the look and feel of code to suit the tastes of an individual developer, it's about configuring code in a consistent and standard way across an organization. The goal is that anyone who looks at your code or anyone else's code in the organization gets to see code that is immediately familiar and readable, regardless of what editor is displaying the code, who's machine the person is sitting at, etc. StyleCop enforces the use of spaces, and in a future version it will enforce the use of exactly four spaces for each level of indentation, to ensure consistent looking code in all situations.
|
|
|
|
|
jasonall wrote:
... it's about configuring code in a consistent and standard way across an organization.
Both spaces and tabs, when used consistently, provide this. And I don't care about customized look and feel of somebody's editor. The only thing I care about is that every file in the source control uses tabs for indentation (it could be spaces, but our coding guidelines say tabs). Why are you insisting on breaking everybody else's rules when you could easily make everybody happy with some way of customization?
|
|
|
|
|
Why are you insisting on breaking everybody else's rules when you could easily make everybody happy with some way of customization?
Source Analysis originated as a Microsoft internal tool which we have decided to release externally so that others can take advantage of it as well, if they would like. The tool enforces one style because that is the style we are driving within Microsoft. Too much customization in a tool like this can ruin the point of the tool, which is to keep all code on the same style. The limited customization is deliberate. Thanks.
|
|
|
|
|
jasonall wrote:
Why are you insisting on breaking everybody else's rules when you could easily make everybody happy with some way of customization?
Source Analysis originated as a Microsoft internal tool which we have decided to release externally so that others can take advantage of it as well, if they would like. The tool enforces one style because that is the style we are driving within Microsoft. Too much customization in a tool like this can ruin the point of the tool, which is to keep all code on the same style. The limited customization is deliberate. Thanks.
Sorry, but forcing development teams to use a style that was, until now, completely undocumented/hidden and therefore different than the rest of the community also ruins the point of the tool. If this Microsoft style was documented (other than Design Guidelines, which is obviously different still to this style mandated by Microsoft Source Analysis for C#) and people could have been following, I could see a point to deliberate limited customization. Teams that are following coding style guidelines must have defined them independently of the Microsoft style guidelines, if this tool doesn't allow them to customize it for their guidelines, it's pointless. Teams that aren't following style guidelines and could blanketly accept the guidelines that this tool mandates, likely don't have a need for a tool like this because they aren't following style guidelines. The logic that customization ruins the point of the tool makes no sense if you can simply disable any rule you like. Logic like that suggest either the tool is not customizable at all or is fully customizable in order to be used with any organization that has existing style guidelines (and I hate to belabour the point, but style guidelines that couldn't possibly be the same as Microsoft's internal C# guidelines).
|
|
|
|
|
Hi Peter,
Calm down. No one is forcing you to use the tool. This is a great tool that Microsoft uses internally for its own purposes. Now they want to share it with the rest of the world. It is not a product. If you like it, go ahead and use it. If not, just walk way. If you don't like specific rules like me, just disable them. I guess that if this tool is transformed in a product (or incorporated as a feature of VS), a great idea is to create a company / organization profile on the server (may be on TFS) instead of hard-coded rules and lock it with a password, forcing all the developers thru organization to use the set of rules specific for the company / organization. Customize profiles to choose the programming language is another helpful feature.
The point is not if this is good or bad, or if it is wrong or right. It is just a standard. The point is that until now this is a Microsoft tool, that follows the Microsoft's own standards and Microsoft wants to share it and extend the benefits of those standards to (and just to) anyone interested to follow it. Is up to you.
|
|
|
|
|
jasonall wrote:
StyleCop is not about configuring the look and feel of code to suit the tastes of an individual developer, it's about configuring code in a consistent and standard way across an organization. The goal is that anyone who looks at your code or anyone else's code in the organization gets to see code that is immediately familiar and readable, regardless of what editor is displaying the code, who's machine the person is sitting at, etc.
StyleCop enforces the use of spaces, and in a future version it will enforce the use of exactly four spaces for each level of indentation, to ensure consistent looking code in all situations.
Announcing soon, for real consistency: "StylePig" - a new tool to enforce a particular font, font size, bg color, bg color, screen resolution, gamma levels, cursor flash frequency, print format, and paper size. StyleCop can only 'ensure consistent looking code in all situations' if it is actually used, but what organization would want to use it if cannot be adjusted, even slightly, to meet their style standard? Echoing Peter above: is the plan to remove the ability to disable rules or to add the ability to add custom rules?
|
|
|
|
|
sergiop wrote: ... Now they want to share it with the rest of the world. ...
Of course we understand this. The frustration is that, with only a small effort, this could be something truely useful. Or at least just codeplex the source code.
|
|
|
Edited May 27 2008 at 8:21 AM
|
|
|
|
|
MatHobbs wrote:
... The frustration is that, with only a small effort, this could be something truely useful. Or at least just codeplex the source code.
+1. Make it open source.
|
|
|
Edited May 27 2008 at 4:58 PM
|
The problem isn't that you can't disable rules like "must use spaces", it's that there is no corresponding rule "must use tabs".
|
|
|
|
|
sergiop wrote:
Hi Peter,
Calm down. No one is forcing you to use the tool. This is a great tool that Microsoft uses internally for its own purposes. Now they want to share it with the rest of the world. It is not a product. If you like it, go ahead and use it. If not, just walk way. If you don't like specific rules like me, just disable them. I guess that if this tool is transformed in a product (or incorporated as a feature of VS), a great idea is to create a company / organization profile on the server (may be on TFS) instead of hard-coded rules and lock it with a password, forcing all the developers thru organization to use the set of rules specific for the company / organization. Customize profiles to choose the programming language is another helpful feature.
The point is not if this is good or bad, or if it is wrong or right. It is just a standard. The point is that until now this is a Microsoft tool, that follows the Microsoft's own standards and Microsoft wants to share it and extend the benefits of those standards to (and just to) anyone interested to follow it. Is up to you.
Apparently you've missed my point: if a team already has style guidelines they can't use this tool.
|
|
|
|
|
MatHobbs wrote:
Echoing Peter above: is the plan to remove the ability to disable rules or to add the ability to add custom rules?
You can already create custom rules. It just takes a bit of code and placing the DLL in the Source Analyzer install directory: http://lovethedot.blogspot.com/2008/05/creating-custom-rules-for-microsoft.html So, if someone wanted to, they could easily create a rule that required each line to start with nothing but tabs. You could probably create a rule that counted the number of tabs and matched it to the curly-brace nesting level to require an exact number of tabs.
|
|
|
|
|
|
|
Edited Jun 24 2009 at 4:01 PM
|
Tabs are not bad! Tabs (default setting) are OK for indenting code blocks. The use spaces instead (two, four?) is horror for me .... Pros for tabs:
- Each developer has the choice for tab size (2 or 4 or ...)
- Collective code ownership made easy
- default setting - often see code mixed spaces and tabs and that makes the code hard to read
- just a single hit onto thy tab key (spaces you have to hit two times)
See also:http://www.irritatedvowel.com/Programming/Standards.aspx All - Use standard tab settings - don't change to 2 characters per tab or anything non-standard like that. Do not replace tabs with spaces.
- Why: When people working in your code have different tab settings, it really makes a huge mess of the formatting. Whenever possible, I avoid fighting the IDE and just go with the flow.
So I was surprised about SA1027 ... PERFECT! A absolutely agree!! Thanks very much for this custom rule!
|
|