views:

2099

answers:

15

I am a PHP web programmer who is trying to learn C#.

I would like to know why C# requires me to specify the data type when creating a variable.

Class classInstance = new Class();

Why do we need to know the data type before a class instance?

+1  A: 

Because C# is a strongly typed language

Nick Allen - Tungle139
Ha ha... you win the flood of answers. Way to keep it short.
JerSchneid
No biscuit so far though LOL
Nick Allen - Tungle139
Static typing is the main reason. Many dynamic languages are also strongly-typed, but they don't need a type declaration.
Jeff Yates
Strong typing and position of the variable name are completely unrelated issues
JaredPar
Common Lisp is also strongly typed, since you can find the type of any object with great precision. It isn't statically typed, because that type can change.
David Thornley
+15  A: 

C# is a statically-typed, strongly-typed language like C or C++. In these languages all variables must be declared to be of a specific type.

Justin Ethier
Well, being strongly typed doesn't always mean you should define the type. For example Ruby, Python and Javascript are strongly typed but uses duck typing instead of static type checking.
Ward Werbrouck
Let's call it statically typed ;-)
Dario
Good point, those languages are strongly-typed with dynamic type checking (IE, runtime). Whereas C# requires the type so it can perform type checking at compile time (IE, static checking).
Justin Ethier
Since this answer has the most upvotes, can someone edit the answer to mention "static type checking at compile time" or something?
Ward Werbrouck
Edited to cover static typing
Jeff Yates
The fact that C# both statically and strongly typed doesn't answer the question of why the type must be on the LHS. These are unrelated issues. Take F# or OCaml as an example. Both are very strongly and statically typed, yet programs can be written without ever explicitly typing a variable and if it is declared it is on the right.
JaredPar
Plain C is arguably statically loosely typed. One thing to keep in mind is that it's not all or nothing - type-systems are a continuum.
troelskn
JavaScript is not strongly typed, it's weakly typed. "1" + 0 will result in "10" (concatenation).
Ionuț G. Stan
+1  A: 

c# is a strongly-typed language, like c++ or java. Therefore it needs to know the type of the variable. you can fudge it a bit in c# 3.0 via the var keyword. That lets the compiler infer the type.

Darren Kopp
+1  A: 

That's the difference between a strongly typed and weakly typed language. C# (and C, C++, Java, most more powerful languages) are strongly typed so you must declare the variable type.

JerSchneid
No, that's the difference between statically and dynamically typed languages. Some languages are strongly typed (in that any object is of determinable type, and obeys the appropriate rules) and don't require declaring the variable type.
David Thornley
+5  A: 

You need [class name] in front because there are many situations in which the first [class name] is different from the second, like:

 IMyCoolInterface obj = new MyInterfaceImplementer();
 MyBaseType obj2 = new MySubTypeOfBaseType();

etc. You can also use the word 'var' if you don't want to specify the type explicitely.

GWLlosa
If you're going to -1 the answer, can you at least leave me a note saying why/where I'm wrong?
GWLlosa
+1 because your answer is perfectly valid from a C# 3 perspective; i.e. the type is optional, the one reason you'd have to state it is because you don't want the choice made by var.
Daniel Earwicker
While this is correct in itself, it does not answer the question at hand, which is why (as in what is the benefit or reasoning) of C# being statically typed.
foljs
The QUESTION was not "why is C# statically typed". The QUESTION was: "Why do I have to specify [classname] twice?" And this answer is: "because its not always redundant." The fact that other people answer "Its statically typed" does not make the question "Why is C# statically typed."
GWLlosa
Of course, as I type this, I notice the question's been edited. Big nevermind.
GWLlosa
+19  A: 

It's simply how the language was designed. C# is a C-style language and follows in the pattern of having types on the left.

In C# 3.0 and up you can kind of get around this in many cases with local type inference.

var variable = new SomeClass();

But at the same time you could also argue that you are still declaring a type on the LHS. Just that you want the compiler to pick it for you.

EDIT

Please read this in the context of the users original question

why do we need [class name] before a variable name?

I wanted to comment on several other answers in this thread. A lot of people are giving "C# is statically type" as an answer. While the statement is true (C# is statically typed), it is almost completely unrelated to the question. Static typing does not necessitate a type name being to the left of the variable name. Sure it can help but that is a language designer choice not a necessary feature of static typed languages.

These is easily provable by considering other statically typed languages such as F#. Types in F# appear on the right of a variable name and very often can be altogether ommitted. There are also several counter examples. PowerShell for instance is extremely dynamic and puts all of its type, if included, on the left.

JaredPar
+1  A: 

When we define variables to hold data we have to specify the type of data that those variables will hold. The compiler then checks that what we are doing with the data makes sense to it, i.e. follows the rules. We can't for example store text in a number - the compiler will not allow it.

int a = "fred"; // Not allowed. Cannot implicitly convert 'string' to 'int'

The variable a is of type int, and assigning it the value "fred" which is a text string breaks the rules- the compiler is unable to do any kind of conversion of this string.

Cuga
+1  A: 

In C# 3.0, you can use the 'var' keyword - this uses static type inference to work out what the type of the variable is at compile time

var foo = new ClassName();

variable 'foo' will be of type 'ClassName' from then on.

thecoop
+19  A: 

One of the main reasons is that you can specify different types as long as the type on the left hand side of the assignment is a parent type of the type on the left (or an interface that is implemented on that type).

For example given the following types:

class Foo { }
class Bar : Foo { }
interface IBaz { }
class Baz : IBaz { }

C# allows you to do this:

Foo f = new Bar();
IBaz b = new Baz();

Yes, in most cases the compiler could infer the type of the variable from the assignment (like with the var keyword) but it doesn't for the reason I have shown above.

Edit: As a point of order - while C# is strongly-typed the important distinction (as far as this discussion is concerned) is that it is in fact also a statically-typed language. In other words the C# compiler does static type checking as compilation time.

Andrew Hare
+1, since this is one of the few that answers with a 'why it works like this' instead of a 'cause it does'.
GWLlosa
+2  A: 

C#, as others have pointed out, is a strongly, statically-typed language.

By stating up front what the type you're intending to create is, you'll receive compile-time warnings when you try to assign an illegal value. By stating up front what type of parameters you accept in methods, you receive those same compile-time warnings when you accidentally pass nonsense into a method that isn't expecting it. It removes the overhead of some paranoia on your behalf.

Finally, and rather nicely, C# (and many other languages) doesn't have the same ridiculous, "convert anything to anything, even when it doesn't make sense" mentality that PHP does, which quite frankly can trip you up more times than it helps.

Rob
(Strongly-typed or weakly-typed) and (static-type-checking or duck-typing). Don't get confused :) Ruby for example is Strongly Typed AND uses duck-typing.
Ward Werbrouck
Yes, Ward. I tend to use the term "fuck typed" to refer to PHP, however...
Rob
+67  A: 

As others have said, C# is static/strongly-typed. But I take your question more to be "Why would you want C# to be static/strongly-typed like this? What advantages does this have over dynamic languages?"

With that in mind, there are lots of good reasons:

  • Stability Certain kinds of errors are now caught automatically by the compiler, before the code ever makes it anywhere close to production.
  • Readability/Maintainability You are now providing more information about how the code is supposed to work to future developers who read it. You add information that a specific variable is intended to hold a certain kind of value, and that helps programmers reason about what the purpose of that variable is.

    This is probably why, for example, Microsoft recommended VB6 programmers put a type prefix with the variable name, but that VB.Net programmers do not.

  • Performance This is the weakest reason, but late-binding/duck typing can be slower. In the end, a variable refers to memory that is structured in some specific way. Without strong types, the program will have to do extra type verification or conversion behind the scenes at runtime as you use memory that is logically structured one way as if it were structured in another.

    I hesitate to include this point, because ultimately you often have to do those conversions in a strongly typed language as well. It's just that the strongly typed language leaves the exact timing and extent of the conversion to the programmer, and does no extra work unless it needs to be done. It also allows the programmer to force a more advantageous data type. But these really are attributes of the programmer, rather than the platform.

    That would itself be a weak reason to omit the point, except that a good dynamic language will often make better choices than the programmer. This means a dynamic language can help many programmers write faster programs. Still, for good programmers, strongly-typed languages have the potential to be faster.

  • Better Dev Tools If your IDE knows what type a variable is expected to be, it can give you additional help about what kinds of things that variable can do. This is much harder for the IDE to do if it has to infer the type for you. And if you get more help with the minutia of an API from the IDE, then you as a developer will be able to get your head around a larger, richer API, and get there faster.

Or perhaps you were just wondering why you have to specify the class name twice for the same variable on the same line? The answer is two-fold:

  1. Often you don't. In C# 3.0 and later you can use the var keyword instead of the type name in many cases. Variables created this way are still statically typed, but the type is now inferred for you by the compiler.
  2. Thanks to inheritance and interfaces sometimes the type on the left-hand side doesn't match the type on the right hand side.
Joel Coehoorn
static and strong typing are NOT the same thing
Jeff Yates
No, but C# does both.
Joel Coehoorn
+1 This is a very thoughtful and concise answer.
Andrew Hare
Good points. Question for someone who seems to understand this topic: Is it possible to have a static/strong typed interpreted language? I haven't seen one, but based on what you've said I don't see why we couldn't have one. I know we wouldn't catch the the type errors at compile time because there isn't one, but it seems like we'd see some of the other benefits(intellisense). After working in C# for years, trying to code in Javascript is driving me crazy because of dynamic typing.
LoveMeSomeCode
Strongly-typed interpreted languages are a little weird, because part of the philosophy of using an interpreter is that you can let it just interpret snippets. When you start having to port class definitions along with the snippets, the interpreter starts losing it's appeal vs a compiled language. But there's nothing stopping you.
Joel Coehoorn
Actually, Java was originally interpreted and it's a strong typed language.
Mystere Man
I might be wrong but I think that clr is like the current jvm in that it jit compiles part of the code but just interprets some parts of the code for which interpreting might be faster then taking the time to run the jit on it.
Roman A. Taycher
Many of the ML family languages (which have very nice flexible static type systems and almost perfect inferring of general types(like var in c# but works almost always ) have both interpreters and compilers. Haskell has hugs, standard ml has HaMLet, ect.
Roman A. Taycher
+1  A: 

One things that hasn't been mentioned is that C# is a CLS (Common Language Specification) compliant language. This is a set of rules that a .NET language has to adhere to in order to be interopable with other .NET languages.

So really C# is just keeping to these rules. To quote this MSDN article:

The CLS helps enhance and ensure language interoperability by defining a set of features that developers can rely on to be available in a wide variety of languages. The CLS also establishes requirements for CLS compliance; these help you determine whether your managed code conforms to the CLS and to what extent a given tool supports the development of managed code that uses CLS features.

If your component uses only CLS features in the API that it exposes to other code (including derived classes), the component is guaranteed to be accessible from any programming language that supports the CLS. Components that adhere to the CLS rules and use only the features included in the CLS are said to be CLS-compliant components

Part of the CLS is the CTS the Common Type System.

If that's not enough acronyms for you then there's a tonne more in .NET such as CLI, ILasm/MSIL, CLR, BCL, FCL,

Chris S
CLS doesn't require static typing.
Pavel Minaev
+5  A: 

Ultimately because Anders Hejlsberg said so...

LWoodyiii
And we should all be grateful.
David Lively
+1  A: 

Why do we need to know the data type before a class instance?

You don't! Read from right to left. You create the variable and then you store it in a type safe variable so you know what type that variable is for later use.

Consider the following snippet, it would be a nightmare to debug if you didn't receive the errors until runtime.

 void FunctionCalledVeryUnfrequently()
 {
   ClassA a = new ClassA();
   ClassB b = new ClassB();
   ClassA a2 = new ClassB(); //COMPILER ERROR(thank god)

   //100 lines of code

   DoStuffWithA(a);
   DoStuffWithA(b);      //COMPILER ERROR(thank god)
   DoStuffWithA(a2);
 }

When you'r thinking you can replace the new Class() with a number or a string and the syntax will make much more sense. The following example might be a bit verbose but might help to understand why it's designed the way it is.

   string s = "abc";
   string s2 = new string(new char[]{'a', 'b', 'c'});
   //Does exactly the same thing

   DoStuffWithAString("abc");
   DoStuffWithAString(new string(new char[]{'a', 'b', 'c'}));
   //Does exactly the same thing
A: 

Static typing also allows the compiler to make better optimizations, and skip certain steps. Take overloading for example, where you have multiple methods or operators with the same name differing only by their arguments. With a dynamic language, the runtime would need to grade each version in order to determine which is the best match. With a static language like this, the final code simply points directly to the appropriate overload.

Static typing also aids in code maintenance and refactoring. My favorite example being the Rename feature of many higher-end IDEs. Thanks to static typing, the IDE can find with certainty every occurrence of the identifier in your code, and leave unrelated identifiers with the same name intact.

I didn't notice if it were mentioned yet or not, but C# 4.0 introduces dynamic checking VIA the dynamic keyword. Though I'm sure you'd want to avoid it when it's not necessary.

YotaXP