Redundancy in C#?

前端 未结 17 1548
猫巷女王i
猫巷女王i 2021-02-13 19:28

Take the following snippet:

List distances = new List();

Was the redundancy intended by the language designers? If so, wh

相关标签:
17条回答
  • 2021-02-13 19:59

    The redunancy wasn't intended, per se, but was a side-effect of the fact that all variables and fields needed to have a type declaration. When you take into account that all object instantiations also mention the type's name in a new expression, you get redundant looking statements.

    Now with type-inferencing using the var keyword, that redundancy can be eliminated. The compiler is smart enough to figure it out. The next C++ also has an auto keyword that does the same thing.

    The main reason they introduced var, though, was for anonymous types, which have no name:

    var x = new {Foo = Bar, Number = 1};
    
    0 讨论(0)
  • 2021-02-13 20:01

    Your particular example is indeed a bit verbose but in most ways C# is rather lean.

    I'd much prefer this (C#)

    int i;
    

    to this (VB.NET)

    Dim i as Integer
    

    Now, the particular example you chose is something about .NET in general which is a bit on the long side, but I don't think that's C#'s fault. Maybe the question should be rephrased "Why is .NET code so verbose?"

    0 讨论(0)
  • 2021-02-13 20:02

    instead of thinking of it as redundant, think of that construct as a feature to allow you to save a line.

    instead of having

    List distances; distances = new List();

    c# lets you put them on one line.

    One line says "I will be using a variable called distances, and it will be of type List." Another line says "Allocate a new List and call the parameterless constructor".

    Is that too redundant? Perhaps. doing it this way gives you some things, though

    1. Separates out the variable declaration from object allocation. Allowing:

    IEnumerable<int> distances = new List<int>();
    // or more likely...
    IEnumerable<int> distances = GetList();
    

    2. It allows for more strong static type checking by the compiler - giving compiler errors when your declarations don't match the assignments, rather than runtime errors.

    Are both of these required for writing software? No. There are plenty of languages that don't do this, and/or differ on many other points.

    "Doctor! it hurts when I do this!" - "Don't do that anymore"

    If you find that you don't need or want the things that c# gives you, try other languages. Even if you don't use them, knowing other ones can give you a huge boost in how you approach problems. If you do use one, great!

    Either way, you may find enough perspective to allow yourself to say "I don't need the strict static type checking enforced by the c# compiler. I'll use python", rather than flaming c# as too redundant.

    0 讨论(0)
  • 2021-02-13 20:02

    C# is definitely getting less verbose after the addition of functional support.

    0 讨论(0)
  • 2021-02-13 20:02

    In many of the answers to this question, the authors are thinking like compilers or apologists. An important rule of good programming is Don't repeat yourself!

    Avoiding this unnecessary repetition is an explicit design goal of Go, for example:

    Stuttering (foo.Foo* myFoo = new(foo.Foo)) is reduced by simple type derivation using the := declare-and-initialize construct.

    0 讨论(0)
提交回复
热议问题