String vs string

[K Viltersten]

At our company, we've been using the standard of string
instead of String. While it's fullly compilable and
valid code, i'd still claim that the type should be
capitalized since it's an object type and not value
type. That's my view.

My coworker is of a different opinion and he argues,
and very rightfully so, that the development this far
has used uncapitalized type and that it'll be
unconvienient to change.

While i agree with his view as a pragmatical approach,
i'd like to "give it to him" and argue to switch to
capitalized type from now on.

Anybody willing to suggest a couple of good shots?
The absolutely best would be a plan to abandon string
and only support String in SOME future version of
DotNet. Can i hope...?

 

[Adrian Sutcliffe]

string is simply an alias for

 

[Joe Fawcett]

string is simply an alias for

Don't keep us waiting...

 

[Joe Fawcett]

At our company, we've been using the standard of string
instead of String. While it's fullly compilable and
valid code, i'd still claim that the type should be
capitalized since it's an object type and not value
type. That's my view.

My coworker is of a different opinion and he argues,
and very rightfully so, that the development this far
has used uncapitalized type and that it'll be
unconvienient to change.

While i agree with his view as a pragmatical approach,
i'd like to "give it to him" and argue to switch to
capitalized type from now on.

Anybody willing to suggest a couple of good shots?
The absolutely best would be a plan to abandon string
and only support String in SOME future version of
DotNet. Can i hope...?

We have a similar argument at my company, I actually use string and int
rather than String and Int32 but the best case I can see for not using the
alias is that it makes converting to another CLR language such as VB.NET
easier.
However I don't think that Microsoft are going to remove the aliases or that
we will convert to VB.NET, especially by hand, so it seems a moot point.

 

[Marc Gravell]

and argue to switch to capitalized type from now on

Frankly: why? What single benefit do you expect this to give you? Having
a mixture of conventions is the worst possible outcome...

and only support String in SOME future version of DotNet.

This isn't a .NET feature; it is a C# feature - but either way - why?
What purpose wuold it serve? I *like* "int" etc; OK, it is only a few
more key-presses, but I uses a *lot* of ints...

[the rest]

value-type vs reference-type shouldn't be the issue here; if you are
following the same approach as the standard framework, then ProperCase
is the way to go for type names. It so happens that the core types
(System.Int32, System.String, System.Decimal etc) have aliases inside
the C# language (int, string, decimal etc).

Again, within C#, many people find it easier to use the aliases (aside:
the aliases also doesn't need a "using System;"). I'm pretty sure it is
recommended to use the aliases where possible - but this is only a
convenience, and does not affect the functioning at all (unless you have
a conflicting class called Int32, which would be crazy).

But this should only be for fields / variables: if the name is in a
public method-name (method *name*, property *name*, etc), you should use
the real type name, i.e.

public int GetInt32() {...}

Since you necessarily don't know what language the caller is using.

 

[Marc Gravell]

Re my last post - I know I was talking about "int" a lot, but as I
mentioned later on, I see no difference at all between value-type and
reference-type re capitalization.

Think DateTime. Think every enum in the system. Think of any other
struct (KeyValuePair<TKey,TValue> perhaps).

class/struct is not the issue here.

 

[Adrian Sutcliffe]

Okay so something went missing in the post!

I was just going to say that since C# type keywords are simply aliases of
the CLR types defined in the System namespace I'm not aware that there is
functionally any difference.

In CLR Via C# Jeffery Richter advocates using the CLR version but I can't
recall the reason without checking the book.

As you go on to suggest I think that the only differences are in how you
might want to work with the codebase in the future (i.e. language conversion)
rather than how the codebase works functionally.

Adria

 

[Jon Skeet [C# MVP]]

At our company, we've been using the standard of string
instead of String. While it's fullly compilable and
valid code, i'd still claim that the type should be
capitalized since it's an object type and not value
type. That's my view.

Where do you get the idea that value types shouldn't be capitalized?

"string" is just a C# short-hand for "System.String". I tend to use
the shorthand forms in code, but use the .NET names for method names
etc (e.g. ToSingle rather than ToFloat) - this doesn't matter in the
case of string.

While i agree with his view as a pragmatical approach,
i'd like to "give it to him" and argue to switch to
capitalized type from now on.

Anybody willing to suggest a couple of good shots?
The absolutely best would be a plan to abandon string
and only support String in SOME future version of
DotNet. Can i hope...?

With the best will in the world, if you don't have good reasons for
doing it that you can already present, why do you feel so strongly
that you *should* use String? Do you write Int32 instead of int? If
not, why not? Value type vs reference type doesn't come into it IMO,
as you won't be able to write guid instead of Guid (etc).

Jon

 

[Barry Kelly]

At our company, we've been using the standard of string
instead of String. While it's fullly compilable and
valid code, i'd still claim that the type should be
capitalized since it's an object type and not value
type. That's my view.

I personally use the C# name for all types that have C# names when I'm
writing C# code.

Value types that don't have C# names don't get lowercase names either,
so arguing object type versus value type is totally irrelevant.

While i agree with his view as a pragmatical approach,
i'd like to "give it to him" and argue to switch to
capitalized type from now on.

Anybody willing to suggest a couple of good shots?
The absolutely best would be a plan to abandon string
and only support String in SOME future version of
DotNet. Can i hope...?

I'd hate to work at a company that made a dogma out of such petty and
unimportant issues.

-- Barry

 

[Chris Shepherd]

My coworker is of a different opinion and he argues,
and very rightfully so, that the development this far
has used uncapitalized type and that it'll be
unconvienient to change.

While i agree with his view as a pragmatical approach,
i'd like to "give it to him" and argue to switch to
capitalized type from now on.

You'll probably live a lot longer, healthier, happier life if you worry less
about minor details like this and be a bit more flexible.
This kind of thing just isn't worth getting worked up over IMO.

Chris.

 

[K Viltersten]

string is simply an alias for

I didn't ask if string is an alias for String.

 

[K Viltersten]

At our company, we've been using the standard of string

We have a similar argument at my company, I actually usestring and int
rather than String and Int32 but the bestcase I can see for not using
the alias is that it makesconverting to another CLR language such as
VB.NET easier.

You're making an interesting point. I'm surprised that you
put string/int in one basket and String/Int32 in an other.
Please correct me if i've misunderstod the idea but i was
told that that a string, being an object type, should be
capitalized to String, while an integer, being value typed,
deserves no such treatment.

Am i mistaken? Please elaborate.

 

[K Viltersten]

At our company, we've been using the standard of string

I personally use the C# name for all types that have C# names when I'm
writing C# code.

Value types that don't have C# names don't get lowercase names either,
so arguing object type versus value type is totally irrelevant.


I'd hate to work at a company that made a dogma out of such petty and
unimportant issues.

Oh, it's not really THAT big issue, just an interesting
topic. My company is really open to "personal touch".
Sorry if i happened to mislead - it wasn't my intention.

 

[K Viltersten]

At our company, we've been using the standard of string

Where do you get the idea that value types shouldn't be capitalized?

I've heard it "somewhere". I focused on the content of the
message and didn't keep track of where i got it. Sorry.

why do you feel so strongly that you *should* use String?

Honestly, i'm not sure.
Perhaps because it's an object...

Do you write Int32 instead of int? If not, why not?

Because int isn't an object. It's value typed.

Value type vs reference type doesn't come into it IMO,
as you won't be able to write guid instead of Guid (etc).

I'm getting the impression that i don't have any case
against my coworker, hehe. Perhaps it's time to admit
the situation. I'll wait until next week, then i'll
declare myself convinced. Thanks!

 

[K Viltersten]

and argue to switch to capitalized type from now on

Frankly: why? What single benefit do you expect thisto give you? Having
a mixture of conventions is theworst possible outcome...

I agree. That's why i wanted to change the company policy
FIRST and then have it my way. I've never claimed it to
be a good one.

This isn't a .NET feature; it is a C# feature - but eitherway - why?
What purpose wuold it serve? I *like* "int" etc;OK, it is only a few
more key-presses, but I uses a *lot*of ints...

It seems that many posters missed what i tried to express.
It was "string" that i wished to change to "String". The
"int" should stay "int" and never (almost) be "Int32". I
repeat - i do not wish to write "Int32". Only "String".

unless you have a conflicting class called Int32

That would go directly to Daily WTF, hehe.

But this should only be for fields / variables: if the nameis in a
public method-name (method *name*, property *name*,etc), you should use
the real type name, i.e.
public int GetInt32() {...}
Since you necessarily don't know what language the calleris using.

Excellent point. I didn't think of that issue.

 

[K Viltersten]

Okay so something went missing in the post!

Sorry i sounded agitated. My bad.

I was just going to say that since C# type keywords are simplyaliases of
the CLR types defined in the System namespace I'mnot aware that there is
functionally any difference. In CLR ViaC# Jeffery Richter advocates
using the CLR version but I can'trecall the reason without checking the
book.

Would be nice to hear what he's saying there. I don't have the
book (read: i'm lazy)...

As you go on to suggest I think that the only differences arein how you
might want to work with the codebase in the future(i.e. language
conversion) rather than how the codebase worksfunctionally.

Perhaps i made it sound like a bigger issue that what it was. My
mistake, sorry. Anyhow, there seems to be a concensus that string
type needs not to be capitalized so i'll be officially accepting
that, effective monday next week. Thanks to everybody!

 

[Jon Skeet [C# MVP]]

You're making an interesting point. I'm surprised that you
put string/int in one basket and String/Int32 in an other.

Um, why? string and int are both C#-specific shorthands. String/Int32
are both the .NET type names. Seems logical to me.

Please correct me if i've misunderstod the idea but i was
told that that a string, being an object type, should be
capitalized to String, while an integer, being value typed,
deserves no such treatment.

Am i mistaken? Please elaborate.

Yes, you're mistaken. I've never heard such a convention proposed
before.

As has been pointed out, there are plenty of value types which are
capitalised: Point, DateTime, Guid etc.

 

[Arne Vajhøj]

At our company, we've been using the standard of string
instead of String. While it's fullly compilable and
valid code, i'd still claim that the type should be
capitalized since it's an object type and not value
type. That's my view.

My coworker is of a different opinion and he argues,
and very rightfully so, that the development this far
has used uncapitalized type and that it'll be
unconvienient to change.

While i agree with his view as a pragmatical approach,
i'd like to "give it to him" and argue to switch to
capitalized type from now on.

Anybody willing to suggest a couple of good shots?
The absolutely best would be a plan to abandon string
and only support String in SOME future version of
DotNet. Can i hope...?

You can not hope.

MS would never break so much code.

There are no functional differences and will likely never be.

The most important aspect is consistency within the project.

So for an existing project you stick with what you have.

For a new project you have a bit more freedom, but you
should go with what is most commonly used.

And my guess would be that string dominates over String
like 75%-25%.

(and int over Int32 at least 99.9%-0.1%)

So I am backing your coworker.

Arne