String vs string

**Adrian Sutcliffe** · Jun 27 '08, 07:52 PM

Re: String vs string

string is simply an alias for

**Joe Fawcett** · Jun 27 '08, 07:52 PM

Re: String vs string

"Adrian Sutcliffe" <adrian@adieswe b.comwrote in message
news:b876da5bff bd8ca89fb9f38d6 f8@msnews.micro soft.com...

string is simply an alias for
>

Don't keep us waiting...

--

Joe Fawcett (MVP - XML)

http://joe.fawcett.name

**Joe Fawcett** · Jun 27 '08, 07:52 PM

Re: String vs string

"K Viltersten" <tmp1@vilterste n.comwrote in message
news:op.ubjmqwg ei74t80@lp028.p agero.local...

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...?
>
--
Regards
Konrad Viltersten

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.

--

Joe Fawcett (MVP - XML)

http://joe.fawcett.name

**Marc Gravell** · Jun 27 '08, 07:52 PM

Re: String vs string

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** · Jun 27 '08, 07:52 PM

Re: String vs string

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<T Key,TValueperha ps).

class/struct is not the issue here.

**Adrian Sutcliffe** · Jun 27 '08, 07:52 PM

Re: String vs string

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.

Adrian

**Jon Skeet [C# MVP]** · Jun 27 '08, 07:52 PM

Re: String vs string

On May 22, 7:53 am, "K Viltersten" <t...@vilterste n.comwrote:

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** · Jun 27 '08, 07:52 PM

Re: String vs string

K Viltersten wrote:

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

--

Entropy Overload

http://barrkel.blogspot.com/

**Chris Shepherd** · Jun 27 '08, 07:52 PM

Re: String vs string

K Viltersten wrote:

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** · Jun 27 '08, 07:53 PM

Re: String vs string

string is simply an alias for

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

--
Regards
Konrad Viltersten

**K Viltersten** · Jun 27 '08, 07:53 PM

Re: String vs string

>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
>unconvienien t 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 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.

--
Regards
Konrad Viltersten

**K Viltersten** · Jun 27 '08, 07:53 PM

Re: String vs string

>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.

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.

--
Regards
Konrad Viltersten

**K Viltersten** · Jun 27 '08, 07:53 PM

Re: String vs string

>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?

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!

--
Regards
Konrad Viltersten

**K Viltersten** · Jun 27 '08, 07:53 PM

Re: String vs string

>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. :)

>and only support String in SOME future version of DotNet.

>
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.

--
Regards
Konrad Viltersten

String vs string

String vs string

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment