List Bezeichner



  • Hey Leute,

    Ich überlege mir derweil ganze Zeit welche speziellen Bezeichner ich für eine List nehmen könnte um diese direkt zu erkennen.

    List<T> _listname;

    wäre meine Methode - wobei ich weiss das "" bei anderen Dingen verwendet wird, habs zumindest mal gesehen. Gibt es da einen inoffiziellen Standart für "" oder kann ich den benutzen ohne das andere "Leser" auf die falsche Fährte geführt werden könnten?

    gruß Charlie



  • Wie wäre es, einen Bezeichner zu wählen, der auf List endet? 😕



  • "_name" wird in C# meist verwendet um Membervariablen zu kennzeichnen. Würde mich sehr wundern wenn ich Code lesen würde wo das "_" was anderes bedeutet.



  • ignoreList schrieb:

    Wie wäre es, einen Bezeichner zu wählen, der auf List endet? 😕

    Sticht nicht so fein ins Auge wie "_" & ist meine momentante Vorgehensweise 😃



  • Falke_tmp schrieb:

    ignoreList schrieb:

    Wie wäre es, einen Bezeichner zu wählen, der auf List endet? 😕

    Sticht nicht so fein ins Auge wie "_" & ist meine momentante Vorgehensweise 😃

    Dann halt _LIST_ . 🤡

    Ansonsten sind afaik auch Unicodebezeichner erlaubt, da findeste bestimmt was auffälliges. 🤡



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



  • 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).


Log in to reply