Integrate Nerdbank Rules

Apr 17, 2011 at 5:40 PM

http://blog.nerdbank.net/2008/09/notrailingwhitespace-stylecop-rule-and.html

Are this 4 rules something you would consider adding to StyleCop's core rules?

Coordinator
Apr 17, 2011 at 6:03 PM
Yes to the notrailingwhitespace rule.


A.



On 17 Apr 2011, at 17:40, "damianh" <notifications@codeplex.com> wrote:

From: damianh

http://blog.nerdbank.net/2008/09/notrailingwhitespace-stylecop-rule-and.html

Are this 4 rules something you would consider adding to StyleCop's core rules?

Apr 18, 2011 at 11:27 AM

How about IndentUsingTabs and NoSpacesBeforeTabs?

(am a tabs over spaces kinda guy)

Developer
Apr 18, 2011 at 2:59 PM

Seems that Andy is quite consistent here.

StyleCop "ships with a single, consistent set of rules, with minimal rule configuration allowed" (see Home page).
And StyleCop default rules are designed for "space indenting" guys.

Third party rules could resolve any other cases.
For instance, you could take a look at StyleCop+ which includes all NerdBank functionality and other rules for "tab indenting" guys.

Best regards,
Oleg Shuruev

Apr 18, 2011 at 3:33 PM

Fair enough.

StyleCop+ , didn't even know about that... thx for the heads up.

Apr 18, 2011 at 3:44 PM

Just looked at StyleCopPlus. Seems it is lagging behind, no build for 4.5.x.0. It's also TFS based. *sigh*

Apr 22, 2011 at 11:04 PM

Using NerdBank custom rules & StyleCop+ together which works fine for me (since StyleCop 4.3.1.3; currently using 4.5 RTW).

Apr 23, 2011 at 5:34 PM
Edited Apr 23, 2011 at 5:35 PM

I would vote for supporting tabs only indentation: a new rule should replace existing DoNotUseTabs and allow 2 modes - spaces only or tabs only - to provide consistency accross all project files (you would be able to only suppress it but not change the mode locally)

Coordinator
Apr 23, 2011 at 6:35 PM
Nope. Consistency says no tabs across all projects.

A.



On 23 Apr 2011, at 17:34, "Alexey_Ru" <notifications@codeplex.com> wrote:

From: Alexey_Ru

I would vote for supporting tabs only indentation: a new rule sould replace existing DoNotUseTabs and allow 2 modes - spaces only or tabs only - to provide consistency accross all project files (you would be able to only suppress it but not change the mode locally)

Apr 23, 2011 at 9:06 PM
Edited Apr 23, 2011 at 9:07 PM

This just forces us to suppress the out-of-the-box rule and maintain our own custom rule to be consisent across OUR projects.

Coordinator
Apr 23, 2011 at 9:50 PM
Yep. I understand. Our goal is consistency across the world.

A.



On 23 Apr 2011, at 21:06, "Alexey_Ru" <notifications@codeplex.com> wrote:

From: Alexey_Ru

This just forces us to suppress the out-of-the-box rule and maintain our own rule to be consisent across OUR projects.

Apr 24, 2011 at 5:59 PM
andyr wrote:
Yep. I understand. Our goal is consistency across the world.

Good luck :D

I think the question is "Consistency" vs. "Collective code ownership" ...

I prefer using tabs for indention for all my projects, because:

  • Each developer has the choice setting her/his preferred indention size (some prefer two, some prefer four, ...)
  • Navigating using the keyboard / cursor keys is much faster and more comfortable than spaces
  • Done this way for many years with success
  • No need to reformat million lines of code
  • (saving storage - just a joke)

Sincerely,
Harald-René Flasch (aka hfrmobile)

Apr 24, 2011 at 6:52 PM

Originally, the spaces were chosen to be consistent across MS code (not across the world). The tool has been made pubilc to be used 'as is': you either accept MS rules or suppress them. And it was understandable. But now, when the tool is not owned by MS, why not give us some freedom to choose? The tabs-vs-spaces choice affects not only how the code looks, but as well the way the people used to work with it (as hfrmobile noted).

Apr 25, 2011 at 3:12 PM
Edited Jul 30, 2012 at 12:55 PM
andyr wrote:
Nope. Consistency says no tabs across all projects.
A.



On 23 Apr 2011, at 17:34, "Alexey_Ru" <notifications@codeplex.com> wrote:

From: Alexey_Ru

I would vote for supporting tabs only indentation: a new rule sould replace existing DoNotUseTabs and allow 2 modes - spaces only or tabs only - to provide consistency accross all project files (you would be able to only suppress it but not change the mode locally)

I agree with Andy. I can recall the days when tabs served a purpose to save disk space. Those days, I respectfully submit are long gone.

Apr 25, 2011 at 3:17 PM
andyr wrote:
Yes to the notrailingwhitespace rule.
A.


I would welcome a non-trailing white space rule, however before such a rule was implemented I respectfully suggest that there needs to be a Visual Studio command for getting rid of trailing white space.  Should one already exist there needs to be adequete publicity about it. Perhaps those nice people at JetBrains should be asked to include it in ReSharper.

Coordinator
Apr 25, 2011 at 3:21 PM
They are adding it to r# 6 I understand.

A.



On 25 Apr 2011, at 15:17, "TATWORTH" <notifications@codeplex.com> wrote:

From: TATWORTH

andyr wrote:
Yes to the notrailingwhitespace rule.
A.


I would welcome a non-trailing white space rule, however before such a rule was implemented I respectfully suggest that there needs to be a Visual Studio command for getting rid of trailing white space. Should one already exist there needs to be adequete publicity about it. Perhaps those nice people at JetBrains should be asked to include it in ReSharper.

Apr 25, 2011 at 7:36 PM
Alexey_Ru wrote:

Originally, the spaces were chosen to be consistent across MS code (not across the world). The tool has been made pubilc to be used 'as is': you either accept MS rules or suppress them. And it was understandable. But now, when the tool is not owned by MS, why not give us some freedom to choose? The tabs-vs-spaces choice affects not only how the code looks, but as well the way the people used to work with it (as hfrmobile noted).

Exactly.

TATWORTH wrote:
andyr wrote:
Nope. Consistency says no tabs across all projects.
A.

"MS Consistency" ... ;-) I remember VS versions where "keep tabs" was the default setting but then MS changed it ^^ ...
Often have (and still) see code where a mix of tabs and spaces are used for indenting. When your editor is set to tabsize=2 (for example) and reading the code which is "optimized for tabsize 4" I wish you lot of fun reading and understanding that code ;-)
I think consistency all over the world is and will be a "Mission Impossible". Even Consistency within MS will be a "Mission impossible". Often seeing/reading code from MSDN etc. and .... consistency!?
Consistency, in my view, could only be achieved in teams/projects and StyleCop is a good buddy helping doing it.
Apr 26, 2011 at 10:34 AM

I agree that consistency is the key where.

But I don't think StyleCop has configurable rules. Does it?

Having a rule for tabs and a rule for spaces would be a valid option. Each project would choose to use one or the other.

Another option would be a unique rule that would act upon the first identation character (tab or space) found in the analysis. If the first found is a space, than all identation characters must be spaces; otherwise tabs.

Apr 26, 2011 at 11:43 AM

StyleCop does support configurable rules.

I don't think the automatic mode selection (depending on the first char) would be a good choice because it will not enforce the same mode for all project files: some of them will be spaces-only, others - tabs-only, and StyleCop will successfully validate all of them. A single rule with mode selection seems to be an ideal solution in this case.

 

Apr 26, 2011 at 9:55 PM
PauloMorgado wrote:

I agree that consistency is the key where.

But I don't think StyleCop has configurable rules. Does it?

Having a rule for tabs and a rule for spaces would be a valid option. Each project would choose to use one or the other.

Another option would be a unique rule that would act upon the first identation character (tab or space) found in the analysis. If the first found is a space, than all identation characters must be spaces; otherwise tabs.

StyleCop lets you choose tabs or spaces. Anyway I recommend using StyleCop+ and NerdBank custom rules too. StyleCop+ offers sophisticated options for that. Don't think that "automatic mode" selection is a good choice since it would not avoid mixes in a project. Consistency within the whole project should be the target ;-)

 

Alexey_Ru wrote:

StyleCop does support configurable rules.

I don't think the automatic mode selection (depending on the first char) would be a good choice because it will not enforce the same mode for all project files: some of them will be spaces-only, others - tabs-only, and StyleCop will successfully validate all of them. A single rule with mode selection seems to be an ideal solution in this case.

 

I agree.

 

Apr 26, 2011 at 11:10 PM
hfrmobile wrote:

StyleCop lets you choose tabs or spaces.

How is that possible? What am I missing?

Apr 26, 2011 at 11:59 PM

Open StyleCop.settings using the Microsoft StyleCop Project Settings Editor:

  1. At the "Enabled rules" (Tree at the left side) expand "Spacing rules"
  2. SA1027: TabsMustNotBeUsed (if enabled, only spaces are allowed, if disabled you are allowed using spaces)

StyleCop+ offers some more settings (rule SP2001: CheckAllowedIndentationCharacters=AllLinesMustUseSpaces|AllLinesMustUseTabs|...)

Apr 27, 2011 at 12:19 AM

Doesn't disabling SA1027 allow a mixture of tabs and spaces and not just tabs?

Where's SP2001?

Apr 27, 2011 at 9:28 AM

Ups .... you're right. It allows a mix ... But when using the NerdBank custom rules it will cause NB1001: "Indention should be done with tabs - not spaces".

SP2001 is a custom rule offered by StyleCop+.

Developer
May 7, 2011 at 9:21 PM

I think one of the biggest issues here is that: StyleCop default settings should not require developers to go in and find and change the default settings of the world's most popular source code editors, just in order for their autoformatting features to work towards compliance rather than fight it every step of the way.  TBH whenever I have to change any settings in Visual Studio from their defaults just for a project I want to work with, that project has unnecessary/annoying setup impedence.

Personally I would not object to alternative/optional rules to be shipped with StyleCop; we already have several that are there but do not start enabled/checked - I could see the addition of other rules which intentionally would not start enabled, so a company could go and disable SA1027 and enable a hypothetical SA1027b "lefthand whitespace must consist of tabs only", then checkin that settings file.  Just like they can go in and disable all documentation rules, or enable others that don't start enabled, and require their developers to use those settings.  But we would still have to draw the line somewhere against the hundreds of potential rules people might maybe potentially sometime someday want for all obscure/specific situations...  because of this I think the most reasonable/defensible place to draw the line is "if it's not an appropriate world-wide default, we're not going to add it to the base StyleCop... try StyleCop+ etc."

Developer
May 7, 2011 at 9:26 PM
Edited May 7, 2011 at 9:45 PM

Anyway, might as well describe one of my main pet peeves with lefthand whitespace:  developers rarely use it correctly for alignment.  For instance, for multi-line statements you might want to align multiple conditions like in this sort of code:

if (reasonably-long-condition1 ||
    reasonably-long-condition2 ||
    reasonably-long-condition3)
{
    ...
}

The code is nice and easy to read/scanthrough when all the conditions align.  However, developers using lefthand tabs almost invariably end up inserting tabs for the whitespace next to condition2 and condition3 and now the code displays different (ugly/difficult) for the developers who have a different tab size.

Developer
May 7, 2011 at 11:14 PM

Just several thoughts about indentation and aligment.

Aligment is probably the worst thing I've ever met in coding style.

First these guys write:

if (condition1 ||
····condition2 

or

while (condition1 ||
·······condition2

and then begin trying to keep this useless "beauty".
It's no wonder that they finally began using spaces not only for aligment, but for indentation too.

I'm not even saying about this:

void MyMethod(string text,
··············int index

or 

int index····= 1;
int index2···= 2;
int index201·= 201;

How anyone can see "beauty" in this, when it tends to be a real headache?
Now you must constantly keep the consistency and change the aligment every time you identifiers are changed.


For me it seems pretty obvious that the real beaty is when you do only indentation, without any aligment.
In this case you don't depend on the lenght of keywords or identifier names.
You just ident one step right when you need it and revert back after that.

And when you do such "indentation-only" style, it's not really a big deal what to use - tabs, or spaces.
I prefer tabs just because of reducing mistake possibility (why to worry if someone accidentally puts 5 spaces instead of 4?).


P.S. Several words about StyleCop+. What is true about it is that:

  1. Support really configurable rules (each rule can have its own rich settings set)
  2. Contains rules for checking indentation characters - you can force tabs, spaces, and several other options.
  3. Contains rules for detecting trailing whitespaces.
  4. Has some lack of documentation, which is temporary I hope.


Best regards,
Oleg Shuruev

May 8, 2011 at 1:10 PM

(For some reason I didn't get the responses to this in my email, and I missed it all.)

> Nope. Consistency says no tabs across all projects.

Consistency also says: "only use tabs across all projects" :)

There really is no point in debating tabs vs spaces, that had been done to death. I don't think it's StyleCop's role to be the world police on what is the 'best' style, otherwise it wouldn't be configurable!

So out of the box, the standard rule is either "TabsMustNotBeUsed" or end up with "Use a mixture of tabs and spaces".

It would make sense to include a "SpacesMustNotBeUsed" for two reasons: as an opposite of SA1027 and because clearly there is a a portion of the community that wants it.

It can be disabled by default, and when setting it, one would have to also disable SA0127... everyone is happy.

May 8, 2011 at 1:54 PM
Edited May 8, 2011 at 1:54 PM

Just an additional thought...

I originally asked this question because I was having some difficulty in with the setting up and distribution of custom rules. Even though I am in a corp environment, I consistently found some people had the rules installed, some removed them because they were out of date etc. So I asked could the rules just be included to solve my problem.

If it were easier to distribute and load custom rules, then perhaps debates such as what rules should be included like above be moot?

Currently, custom rules have to be installed into the stylecop installation directory in %ProgramFiles(86)%. This is a large development 'environment' impact - the custom rules are then available globally to every project, personal, work and oss. (This is a problem with Visual Studio in general - MS expects it to be used in standardized corporate environment and everyone has has the same setup and settings)

I would really like to be able to distribute my custom rules with my projects (or via NuGet), point to them perhaps via StyleCop.setting files and have StyleCop dynamically load them. This would be great degree of isolation and could be a work around the above debate.

Maybe the entire StyleCop runtime and rules engine could be bin distributable with the VS plugin just being a lightwight bootstrapper? Hmm, the more I think about that the more I like that idea...

Jul 27, 2012 at 8:48 PM

Hello,

Maybe late, but the trailing space rule needs to be a little intelligent. When refactoring code with Resharper, and even (I think) reformating code with the standard code reformat of Visual Studio, both will add a space when splitting your code lines at commas. So, if you have a very long string.format line and a monstruous number of arguments, chances are, you are going to have a space after the comma on your first line.

I have added such rule to my custom rule package, which may contains other rules Andy could consider, but this is not a submission, its simply my 2 cents warning.

There is also the StyleCode R# plugin that allows you to add automatically your header with all the arguments. If I am not mistaken, there will be a space at the end of all argument names.

My rule package is geared towards "Clean Code" and how Robert C. Martin sees how code should be written.

And by the way, none of those rules go against any rule of StyleCop. I currently run all StyleCop rules as well as the one in my package.

http://code.google.com/p/cleancodersstylecoprules/

Jeff

Dec 10, 2012 at 5:08 PM
andyr wrote:
Yes to the notrailingwhitespace rule.

 

Quite some time ago, I proposed that as a new feature. However, as its still only "proposed" and also unassigned I'm not sure if you are working on this or not.

 

Can you please clarify if you will include this rule or not?

Thanks

Bernhard