List Bezeichner



  • Th69 schrieb:

    Warum nicht einfach nur "Names"? Explizit den Typ dazu zuschreiben käme dann ja wiederum der verpöhnten Ungarische Notation gleich.

    Das stimmt zwar, aber ich hänge trotzdem oft ein "List" an, weil mich z.B. bei

    foreach (var name in names)
      Process(name);
    

    immer nervt, dass sich "name" und "names" optisch nicht groß unterscheiden und es auch mit IntelliSense nervig wird, weil ich dann oft das falsche erwische ^^

    Insofern mache ich

    foreach (var name in nameList)
      Process(name);
    

    und finde, dass sich das angenehmer liest. Bin mir aber bewusst, dass es eig. nicht so der Hit ist, den Typ im Variablennamen zu haben.



  • Nunja bei ner List ist es aber glaube ich ganz Ok - macht man ja auch bei nem Array habe ich bei C damals zumindest so gemacht.



  • Falke_tmp schrieb:

    Nunja bei ner List ist es aber glaube ich ganz Ok - macht man ja auch bei nem Array habe ich bei C damals zumindest so gemacht.

    Ein guter Tag ist ein Tag mit Wirsing.



  • GPC schrieb:

    Th69 schrieb:

    Warum nicht einfach nur "Names"? Explizit den Typ dazu zuschreiben käme dann ja wiederum der verpöhnten Ungarische Notation gleich.

    Das stimmt zwar, aber ich hänge trotzdem oft ein "List" an, weil mich z.B. bei

    foreach (var name in names)
      Process(name);
    

    immer nervt, dass sich "name" und "names" optisch nicht groß unterscheiden und es auch mit IntelliSense nervig wird, weil ich dann oft das falsche erwische ^^

    Insofern mache ich

    foreach (var name in nameList)
      Process(name);
    

    und finde, dass sich das angenehmer liest. Bin mir aber bewusst, dass es eig. nicht so der Hit ist, den Typ im Variablennamen zu haben.

    🤡

    List<Polygon>  listPolygons = buildpolygon.BuildPolygonText(startCharPos, endCharPos);
    
                // draw polygons
                foreach (Polygon temp in listPolygons) 
                {
                    canvas1.Children.Add(temp);
                }
    

    Solche Fragen sind seit Guidance in Context überfüssig.



  • Prof84 schrieb:

    Solche Fragen sind seit Guidance in Context überfüssig.

    Solche Antworten auch. 🤡
    https://www.google.de/?gws_rd=ssl#newwindow=1&q=Guidance+in+Context



  • + 2 min 😃



  • GPC schrieb:

    Das stimmt zwar, aber ich hänge trotzdem oft ein "List" an, weil mich z.B. bei

    foreach (var name in names)
      Process(name);
    

    immer nervt, dass sich "name" und "names" optisch nicht groß unterscheiden und es auch mit IntelliSense nervig wird, weil ich dann oft das falsche erwische ^^

    Das Problem ist die redundante name -Variable. Man kann das hier auch anders schreiben:

    names.ForEach(Process);
    


  • Klar, aber es gibt auch Schleifen mit komplizierterem Body, der nicht in einem ForEach + Lambda verschwindet 😉



  • Zusätzlich setzt das auch die Nutzung von .NET > 2 voraus. Bei uns im Unternehmen gibt es (wenn nicht anders vom Kunden spezifiziert) die Anweisung Anwendungen in .NET 2 zu schreiben. Dort fällt das names.ForEach schonmal weg.



  • Selbst für .NET 2 gibt es LINQ: LINQ for .NET 2.0
    Also auf die Annehmlichkeiten würde ich nicht mehr verzichten.



  • Th69 schrieb:

    Selbst für .NET 2 gibt es LINQ: LINQ for .NET 2.0
    Also auf die Annehmlichkeiten würde ich nicht mehr verzichten.

    Nicht schlecht 🙂

    Aber ForEach ist keine Linq-Extension-Methode, sondern einfach eine normale Methode von List<T>, insofern hilft dieser Backport da jetzt nicht wirklich 😉



  • Stimmt, war bisher der Meinung dass diese Methode mit Linq dazu kam.



  • Ist aktuell bei mir auch ein Thema: List<T> mit LINQ to object.

    Das Nervige ist, dass Du "zweisprachig" agierst - List-Funktionen und LINQ Quere.
    Denglish in formalen Sprachen. Mit Lambda-Ausdrücken wird es sogar ganz krass.
    Zumal LINQ manche SQL-Aussdrücke nicht kennt, wie insert, delete etc.

    Seit dem habe ich so einen pathologischen Refactoring-Drang. 😞



  • Prof84 schrieb:

    Zumal LINQ mache SQL-Aussdrücke nicht kennt, wie insert, delete etc.

    Natürlich nicht. Linq ist eine reine Abfragesprache und nach der funktionalen Denkweise "ohne Seiteneffekte" entworfen (deshalb gibt es auch kein ForEach als Linq-Extensionmethode).



  • GPC schrieb:

    Prof84 schrieb:

    Zumal LINQ mache SQL-Aussdrücke nicht kennt, wie insert, delete etc.

    Natürlich nicht. Linq ist eine reine Abfragesprache und nach der funktionalen Denkweise "ohne Seiteneffekte" entworfen (deshalb gibt es auch kein ForEach als Linq-Extensionmethode).

    Ich weiß! - Ich denke wohl zu stark in Domains ... 🙄


Anmelden zum Antworten