Aelo schrieb:
H
Abkürzen von Variablen ist in Java vielleicht üblich, aber C# werden sie eher ausgeschrieben.
Da hast du vollkommen Recht. Das Abkürzen von Variablennamen ist eine Unart aus der alten C-Zeit und sollte immer vermieden werden, da sich unter sr niemand etwas vorstellen kann, erst recht nicht, wenn es mehr Variablennamen und Klassen sind.
* Verwende gleich englische Variablennamen, das ist nämlich Industriestandard.
Auch hier kann ich dir nur zustimmen. Das liegt aber weniger daran, dass es Industriestandard ist, sondern dass sich Variablen im Englischen einfach deutlich einfacher und direkter benennen lassen, als im Deutschen.
* Für das herausfinden der ersten und letzten Elemente kannst du Linq verwenden denn für genau solche Dinge wurde das entwickelt :-).
Linq benötigt .NET 3.5. Falls möglich sollte man sich auf die Features von .NET 2.0 beschränken, falls die Software nicht nur auf dem eigenen Entwicklungsrechner laufen soll. .NET 2.0 sollte auf 95% der Rechner schon oben sein und hier liefere ich meistens nicht einmal einen Installer mit dem Hauptprogramm mit. Bei .NET 3.5 ist das schon ziemlich eine Prozedur, Windows 2K Rechner werden grundsätzlich nicht unterstützt und es gibt auch gelegentlich Fälle, wo die Installation schief geht und man außer Systemwiederherstellung nur mehr den Rechner neu aufsetzen kann. Bei einem Kunden vielleicht noch auf dem Server sollte man sich gut überlegen, ob man den Schritt wirklich geht. Auch das schnelle Herunterladen von der Homepage ist dann vorbei, wenn man 200MB fürs .NET Framework braucht.
* try und catch sollte man nur in den verwenden wenn nicht anders möglich. Wenn ein File nicht gefunden wird solte hier auch die passende Exception geworfen werden und nicht einfach nichts passieren.
Grundsätzlich sollte man über jeden Event, der direkt vom GUI aufgerufen wird ein Try Catch haben, indem man grundsätzlich jede Exception fängt, diese anzeigt und in eine Logdatei (oder ähnliches) schreibt. Man kann nie alle Fehler einzeln bedenken und behandeln. Hier ist es besser alles pauschal zu behandeln (z.B. ein Fehler beim Laden führt zum Beenden des Programms, ein Fehler in einem Thread des Servers zum Schließen der Verbindung etc.) und nachher kann man bekannte Fehler immer noch getrennt behandeln.
Hier gilt es immer zwischen Benutzerfreundlichkeit und Wartbarkeit des Codes abzuwägen. Mehr abgefangene Fehler vergrößern den Code und machen ihn unübersichtlicher, bieten aber eventuell bessere Fehlertexte für Benutzer.
Es empfiehlt sich auch in erster Linie die direkte Fehlerursache Anzuzeigen und dann einen möglichen Behebungsvorschlag z.B. "Datei File01.xyz konnte nicht geöffnet werden. Bitte legen Sie die Datei an und stellen Sie sicher, dass der Benutzer darauf zugreifen kann:\n\n" + ex.toString()
Des weiteren ist es sehr hässlich im Code selbst Namespaces anzugeben! (Mit SHIFT+ALT+F10 kannst du sofern du gerade mit dem Mauszeiger in der Variable bist die usings automatisch hinzufügen und dann brauchst du die Namespaces nicht mehr anzugeben...)
Das ist zum größten Teil Geschmackssache. Ganze Namespaces sind unübersichtlich. Zu tief sollte man jedoch auch nicht gehen. Im Normalfall ist es am Besten bis zum letzten Namespace einzubinden (z.B. System.IO), jedoch keine Klassen (z.B. System.IO.StreamReader), weil es da oft zu Namenskonflikten kommen kann. Bei möglichen Namenskonflikten zweier Klassen nehme ich immer entweder nur den Klassennamen, oder den vollständigen Pfad (System.IO.StreamReader), aber nie eine Mischlösung (IO.StreamReader)
wenn du möchtest kannst du auch das using-weglassen, dann musst du eben nach dem du mit dem lesen des File fertig bist die .Dispose()-Methode aufrufen. Denn etwas anderes macht das using auch nicht...
Das using macht sowieso nur in einigen Fällen Sinn, da zusätzlich zum Aufrufen der Dispose Methode eventuell noch andere Aktionen gesetzt werden müssen. Falls eine Exception auftritt vertraue ich immer mehr auf die .Close Methode der jeweiligen Klasse (natürlich in einem weiteren Try Catch Block), als auf die .Dispose Methode. Gerade bei Softwarebibliotheken von Drittherstellern, würde ich nicht davon ausgehen, dass die ordentlich implementiert ist.
antred schrieb:
Wenn schon, dann aber richtig. Die Vergangenheit von "split" ist "split", nicht "splitted".
SplitLine kann aber auch der Name für eine Funktion sein. Ich würde hier immer die gramatikalisch falsche, aber eindeutige Variante bevorzugen.
Ich hätte auch kein Problem eine deutschle Klasse Teebeutel in der Mehrzahl einfach stur Teebeutels zu benennen. Ein Variablenname soll die Bedeutung einer Variable möglichst eindeutig beschreiben, nicht mehr und nicht weniger.