Wie wirkt sich die Berücksichtigung der Typinferenz auf die Wartbarkeit des Codes aus?

Question

Obwohl die Beispiele in dieser Frage in Visual Basic.NET und Java enthalten sind, ist es möglich, dass das Thema auch auf andere Sprachen angewendet werden kann, die Typinferenz implementieren.

Bis jetzt habe ich nur Typinferenz verwendet, wenn Sie LINQ in VB.NET verwenden. Ich bin jedoch, dass Typinferenz bewusst in anderen Teilen der Sprache verwendet werden, wie unten gezeigt:

Dim i = 1 'i is inferred to be an Integer 
Dim s = "Hoi" 's is inferred to be a string 

Dim Temperatures(10) as Double 

For T In Temperatures  'T is inferred to be a Double 
    'Do something 
Next 

Ich kann sehen, wie Typinferenz die Menge der Typisierung reduziert ich brauchen würde, ein Stück Code schreiben Außerdem können Sie den Typ einer Basisvariablen (z. B. Temperatures(10)) schneller ändern, da Sie die Typen aller anderen Variablen, die darauf zugreifen, nicht ändern müssen (z. B. T). Ich war jedoch besorgt, dass das Fehlen einer expliziten Deklaration des Typs den Code schwerer lesbar machen würde, etwa während einer Code-Inspektion, da es nicht sofort offensichtlich ist, welcher Typ eine Variable ist. Wenn Sie beispielsweise nur die obige For-Schleife betrachten, nehmen Sie möglicherweise an, dass T ein Gleitkommawert ist, aber nicht in der Lage ist, zu bestimmen, ob es sich um Einzel- oder Doppelpräzision handelt, ohne auf die Deklaration von Temperatures zurückzublicken. Abhängig davon, wie der Code geschrieben wird, könnte Temperatures viel früher deklariert werden und würde daher erfordern, dass der Leser zurückgeht und die Deklaration findet und dann das Lesen wieder aufnimmt. Zugegeben, wenn man eine gute IDE benutzt, ist das nicht so ein Problem, da ein schneller Mauszeiger über den Variablennamen den Typ anzeigt.

Auch würde ich mir vorstellen, dass die Verwendung von Typ-Inferenz in einigen Situationen einige Fehler beim Versuch einführen könnte, den Code zu ändern. Betrachten Sie das folgende (zugegebenermaßen konstruierte) Beispiel, unter der Annahme, dass die Klassen A und B ganz andere Dinge tun.

Class A 
    Public Sub DoSomething() 
    End Sub 
End Class 

Class B 
    Public Sub DoSomething() 
    End Sub 
End Class 

Dim ObjectList(10) As A 

For item In ObjectList 
    item.DoSomething() 
End For 

Es ist möglich, die Art des ObjectListA-B und der Code würde kompilieren zu ändern, würde aber anders funktionieren, was als Fehler in anderen Teilen des Codes manifestieren könnte.

Mit einigen Beispielen der Typschlussfolgerung würde ich mir vorstellen, dass die meisten Leute zustimmen würden, dass seine Verwendung keine negativen Auswirkungen auf die Lesbarkeit oder Wartbarkeit hat. Zum Beispiel in Java 7 können die folgenden verwendet werden:

ArrayList<String> a = new ArrayList<>(); // The constructor type is inferred from the declaration. 

statt

ArrayList<String> a = new ArrayList<String>(); 

Ich war neugierig zu erfahren, was die Gedanken der Menschen zu diesem Thema sind und ob es irgendwelche Empfehlungen, wie ausgiebig Typ-Inferenz sollte verwendet werden.

Amr

Answer 1

Persönlich neige ich dazu, in Fällen, nur implizit Typinferenz zu verwenden, wo die Art klar ist und wo es der Code macht leichter zu lesen

var dict = new Dictionary<string, List<TreeNode<int>>>(); 

einfacher ist

zu lesen als

Dictionary<string, List<TreeNode<int>>> dict = 
    new Dictionary<string, List<TreeNode<int>>>(); 

noch die Typ ist klar.

---

Hier ist nicht wirklich klar, was man bekommt, und ich würde den Typ explizit angeben:

var something = GetSomeThing(); 

---

Hier macht es keinen Sinn var zu verwenden, da er nichts vereinfachen

Answer 2

Die Verwendung von Generics ist typsicher Prüfung bei der Kompilierung, um sicherzustellen, anstatt sie auf der Laufzeit der Handhabung. Wenn Sie type safe korrekt verwenden, werden Sie sowohl vor Laufzeitausnahmen geschützt als auch zum Zeitpunkt des Datenabrufs Casting-Codes schreiben.

JAVA Verwendet diesen Sentax nicht vor jdk 1.7

ArrayList<String> a = new ArrayList<>(); 

Seine

ArrayList<String> a = new ArrayList(); 

Aber in Java die Verwendung von

ArrayList<String> a = new ArrayList(); and 
ArrayList<String> a = new ArrayList<String>(); 

Beide betrachten gleich, weil die Bezugsgröße die complile Zeitinformationen vom Typ sicher dem hält, ist String kann man nicht etwas anderes statt String darin fügen dh

a.add(new Integer(5)); 

Es ist immer noch sicher und Sie erhalten den Fehler, dass Sie nur Strings einfügen können.

Sie können also nicht das tun, was Sie zu tun, erwarten zu.

Answer 3

denke ich, teilweise ist es eine Frage Art der Codierung. Ich persönlich gehe mit dem etwas ausführlicheren Code zur Wahl. (Auch wenn ich zu einem Java 7-Projekt übergehe, werde ich wahrscheinlich die neue Syntax nutzen, da alles noch immer in einer Zeile vorhanden ist.)

Ich denke auch, dass das explizite Schreiben bestimmte kleine Fehler vermeiden kann. Nehmen Sie Ihr Beispiel:

For T In Temperatures  'T is inferred to be a Double 
    'Do something 
Next 

Wenn Do something war ein numerisches Verfahren, das auf T ein Double sein verließ, dann Temperatures auf einfache Genauigkeit ändern könnte ein Algorithmus zum Scheitern führen zu konvergieren, oder auf einen falschen Wert zu konvergieren.

Ich kann mir vorstellen, dass ich anders argumentieren könnte — dass Explizit über variable Typen in bestimmten Fällen eine Menge trivialer Wartungsarbeiten erzeugen kann, die hätten vermieden werden können. Auch hier ist es eine Frage des Stils.