Implizite oder Explizite Deklarierung

  • C#

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von Koopakiller.

    Implizite oder Explizite Deklarierung

    Guten Tag,
    Eigentlich steht die Frage schon oben,aber es gibt in c# ja die implizite Deklarierung mit var,oder die explizite Deklarierung in form von

    Quellcode

    1. Typ Bezeichner = Wert;
    .
    Benutzt ihr die implizite oder explizite Deklarierung und wieso?
    Hallo, meistens die expliziete, damit ich bei der Deklaration nur das erste Wort lesen muss damit ich weiß was es ist. Das var-Schlüsselwort ist in manchen Fällen auch ganz Hilfreich, das nutze ich beispielsweise für Events:

    Quellcode

    1. var v = MyEvent;
    2. if(v != null)
    3. v(this, EventArgs.Empty);

    Ansonsten findet das bei mir kaum Verwendung.
    EDIT: Es wäre vor allem übersichtlicher.

    int test ist schöner als var test

    Hab erst jetzt richtig gelesen. Nicht Konvertierung sondern Deklarierung xD

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „programmer71“ ()


    personally only use “var” when I can clearly distinguish the variable Type by just reading the declaration, for example:

    var someVariable = new List<int>();
    In the example above, its evident that “var” refers to “List<int>”.

    I don’t like to use “var” when I have to go to some method definition to find out what variable type “var” represents or by having to rely on visual studio intelli-popup or whatever that is called, for example this in not ok to me:

    var someVaraible = SomeMethod();
    I mean, what is the “SomeMethod” function supposed to return? Can you tell just by looking at the line of code? No you can’t, so that is why I avoid using “var” on those situations.

    (stackoverflow.com/questions/65…tly-typed-local-variables)

    Auch meine Meinung ;)
    Lies mal das: resharper.blogspot.de/2007/08/…-30-implicitly-typed.html (unter "to var or not to var?")
    nakullande.wordpress.com/2011/…licit-variable-in-net3-0/

    Ein direkten Perfomace-Vergleich hab ich nicht gefunden. Wahrscheinlich gibt sich das nicht viel.
    Edit:
    There's no extra IL code for the var keyword: the resulting IL should be identical for non-anonymous types. If the compiler can't create that IL because it can't figure out what type you intended to use, you'll get a compiler error.
    /nicht getestet
    Kommt drauf an. Bei primitiven Datentypen verwende ich var nicht, weil diese sowieso kurz sind.
    Nur wenn sowas stehen würde:

    C#-Quellcode

    1. System.Collections.ObjectModel.ObservableCollection<System.Threading.Thread> Foo = new System.Collections.ObjectModel.ObservableCollection<System.Threading.Thread>();

    verwende ich var, weil es unnötige, doppelte Schreibarbeit wäre.

    C#-Quellcode

    1. var Foo = new System.Collections.ObjectModel.ObservableCollection<System.Threading.Thread>();


    Hingegen, wenn die Initialisierung nicht in der selben Zeile wie die Deklaration möglich ist, oder eine Initialisierung mit null vorgesehen ist, kann man var logischerweise nicht verwenden. Dann muss man den Typ angeben (und sollte man auch weil wegen lesbarkeit).
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    @Niko Ortner
    Also ich Tippe in einem solchen Fall folgendes:
    ObservableCollection<Thread > [Strg]+[.] [Enter] > [Strg]+[.] [Enter] > Foo = new > [Enter] > ();
    Dadurch spart man sich einiges...
    IntelliSense zu beherschen ist teilweise eine Kunst, aber wenn man es kann, dann ist man klar im Vorteil.
    @Koopakiller: Dieses kleine Fensterchen, das bei Strg+Punkt kommt, würde ich mir auch in VB wünschen.
    Wobei ich dazu sagen muss, dass das nur ein Beispiel war, das die lange Schreibweise veranschaulichen soll.
    Sehr praktisch finde ich übrigens auch, dass direkt der komplette Bezeichner vorgeschlagen wird (also dass man nach "new" nur noch Enter drücken muss).
    Allerdings sieht das hier:

    C#-Quellcode

    1. void Bla()
    2. {
    3. var Foo = new System.Collections.ObjectModel.ObservableCollection<System.Threading.Thread>();
    4. }

    meiner Meinung nach immer noch wesentlich übersichtlicher aus als das hier:

    C#-Quellcode

    1. void Bla()
    2. {
    3. System.Collections.ObjectModel.ObservableCollection<System.Threading.Thread> Foo = new System.Collections.ObjectModel.ObservableCollection<System.Threading.Thread>();
    4. }

    (BTW: Wenn man was ändern möchte, muss man es bei var nicht zweimal ändern.)
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    @Niko Ortner
    Beim Ändern hast du natürlöich recht. Auch wenn es bei mir biusher njie zugetroffen hat.
    Übersichtlicher: Ansichtssache...;)

    PS: Das Fenster vermisse ich auch etwas in VB...die Unterschiede zwischend en Sprachen liegen meiner Meinung anch manchmal mehr in der IDE als in den Sprachen selbst.
    @Koopakiller:
    manchmal mehr in der IDE als in den Sprachen selbst.

    Das denke ich auch. Beispielsweise vermisse ich bei C# hin und wieder die projektweiten Namespace-Importe.
    Hingegen werden zum Beispiel bei folgendem:

    VB.NET-Quellcode

    1. Dim BackGroundBrush As SolidBrush
    2. '...
    3. Protected Overrides OnPaint(e As PaintEventArgs)
    4. e.Graphics.FillRectangle(
    5. End Sub
    , sobald man in der Zeile 4 die Klammer öffnet, nur Member der Brushes-Klasse angezeigt. Wenn man dann nach und nach BackGroundBrush eingibt, macht Intellisense nicht mit und zeigt die Variable einfach nicht an.
    Wobei inzwischen ein ServicePack herausgekommen ist, bei dem das geändert wurde.

    Da gibt's einige Sachen die beide Seiten voneinander abschauen könnten.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    Ich bin der selben Meinung. Nur leider sind nicht alle so verständlich und akzeptieren die aandere Sprache so wie ihr. Ich hätte mir nie vorstellen können mal VB zu benutzen, doch ich kam einfach durch zufall darauf, weil ich C# gelernt habe.
    Und wie lange es dauert bis Microsoft mal eine Entscheidung wirklich entschieden hat, dauert es leider, manchmal wörtlich ewig. :(