10

Working within Visual Studio 2015, I have a conditional check to the effect of:

if(String.IsNullOrWhiteSpace(stringToTest))

And I saw an IDE001 quick tip or action suggesting that the "Name can be simplified" with a suggested correction of: 

if(string.IsNullOrWhiteSpace(stringToTest))

With the only difference being to use string instead of String.

full quicktip

MSDN examples use an uppercase S with String, and this SO answer clarifies that "string is an alias in C# for System.String. So technically, there is no difference."

And to be clear, my question relies upon the answers within String vs. string, but I have a different question than what is asked there.

Also related is this SO question, although the answers there don't really address the question. That particular question is very similar to mine, however it is marked as a duplicate of the other SO question I noted. And there is a comment by the OP indicating this is brand new behavior only seen in 2015.

My Question

My question is that if the two variable types are equivalent, and MS examples use the upper case version, why am I seeing quick actions to use the lower case version? Was there a change in the .NET 4.6 framework and VS2015 to encourage using the lower case version? It doesn't seem like I should be seeing that type of a tip.

Community
  • 1
  • 1
  • what do you mean by quick tips? In Visual Studio, on MSDN or ...? – Sergey Jan 04 '16 at 19:01
  • 3
    This question is already the first Google result for "IDE001 quick tip". I think that's proof enough that you ought to define this term. – Lightness Races in Orbit Jan 04 '16 at 19:02
  • I would *guess* that the rule is pretty generic (String->string throughout your code) and would make sense most of the time, as typically you want to say things like `string foo = "bar"` rather than `String foo = "bar"`. It just doesn't work for the case of static method calls, where the class name is more common. – adv12 Jan 04 '16 at 19:03
  • 1
    @Pierre-LucPineault: Hardly. – Lightness Races in Orbit Jan 04 '16 at 19:03
  • No, there were no changes. You can use either. – Tdorno Jan 04 '16 at 19:03
  • @LightnessRacesinOrbit Yeah, but the accepted answer shows both are technically the same, explains the guidelines and even talk about StyleCop, which is pretty similar to OP's question. – Pierre-Luc Pineault Jan 04 '16 at 19:07
  • It's probably encouraging the lower-case casing to be consistent with other aliases. I try to avoid the upper-camelcase to prevent others who look at my code from seeing the green text of calling a class. It can lead to confusion. – Drew Kennedy Jan 04 '16 at 19:08
  • 2
    @Pierre-LucPineault - They are similar, but different. I wouldn't expect to see the quick tip that I am based upon the answer in the other SO question –  Jan 04 '16 at 19:08
  • @GlenH7 Well the answer states the guidelines may have changed since StyleCop already moved their recommendation to the alias a while ago (2012). Looks like the same thing happened with the quick tip to consolidate this new guideline. – Pierre-Luc Pineault Jan 04 '16 at 19:11
  • 2
    While this question is indeed a technical duplicate of http://stackoverflow.com/q/32187486/560648, this one is _much_ better than that one, which also has fairly terrible answers that miss the mark and has itself been false-dupe-closed. I consider this to be one of those exceptions where this question deserves to stand on its own. Hence a reopen vote from me. – Lightness Races in Orbit Jan 04 '16 at 19:19
  • @LightnessRacesinOrbit There are [other similar duplicates as well](http://stackoverflow.com/questions/31532718/visual-studio-2015-code-style-settings). I agree this one is better written, given that there is a lot more descriptive text rather than just images. However I think SLaks' answer in the linked duplicate is applicable to this question. There are two related style options that can be set to change whether this code fix appears. – Mike Zboray Jan 04 '16 at 19:33
  • @mikez - SLaks's answer tells you how to make this go away but doesn't explain _why_ this is now occurring. This appears to be a change with 2015 and that's what I'm looking for an answer about. –  Jan 04 '16 at 19:34
  • 1
    @mikez: The question doesn't ask for an option that can be set to change whether this code fix appears. Neither did the original question. That's the problem! SLaks's answer is in fact not an answer to either question. – Lightness Races in Orbit Jan 04 '16 at 19:41

4 Answers4

4

Well, as smarter than me have noted there's actually no difference in the compiling level, and like you (and like JohnyL as you'll see ;), I also thought it's a bug and got to what's leading me to my answer:

why am I seeing quick actions to use the lower case version?

Taken from this informative (and funny) bug discussion, these are the main points for this feature:

  • It doesn't just change the letter case, it replaces the String type name with the string keyword. The fact that the 2 happen to differ only by case is a coincidence. There are cases where the number of characters is different (Int32 -> int) or the name is completely different (Single -> float).
  • Lower case names are easier to type.
  • For people that actually prefer the consistent format of string in the code (it's probably dependent on other languages you code in and their conventions) this feature helps change existing source code to be consistent.
  • string is also a keyword with a well defined meaning while String's meaning may be different depending on context.

Was there a change in the .NET 4.6 framework and VS2015 to encourage using the lower case version?

As far as I've read, No.

BTW, you can change this behavior to suit your preference in Tools > Options > Text Editor > C# > Code Style -> Uncheck "Prefer intrinsic predefined type keyword in member access expressions".

Moshisho
  • 2,781
  • 1
  • 23
  • 39
3

I am only speculating, but it seems to me that the quick tip is intended to help you simplify System.String to string, ignoring the fact that your usings have made it redundant, at least in terms of character-counting.

Call it a bug (albeit an extremely minor one) or at least the IDE getting overzealous. One could argue that this is a valid simplification in a broader sense, particularly if you are to use these short "aliases" consistently in your code. As a C++ developer, I'm not really seeing it, but there you go.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
1

There is no difference for compiler but IDE quick fixes are also used for ensuring good styling (e.g. naming conventions). You are programming in C# so you're expected to use its features (in this case - bultin type alias).

I think you are using int instead of Int32, right? So the same is for string and String. Although there is no real difference in length for string technically this is still similar case.

Vlad
  • 3,001
  • 1
  • 22
  • 52
0

I have a suspicion that the primary reason for changing System.String to string is because it is regarded as a primitive .NET. And since all primitives have aliases - System.Int32 -> int, System.Char -> char etc., for consistency-sake, "string" is treated the same. Looking through all sorts of other MSDN documentation you'll see the two being used interchangeably; I think that's a simple oversight on their part.

Whether its warranted or not, I'm still going to use string over String as the quick tips suggest. Sounds like an example of Grandma's Cooking Secret, but is there a reason to change that behavior in this case?

Balah
  • 2,530
  • 2
  • 16
  • 24