Erstes C#-Project - ASCII-Tabelle - Bitte um Kritik
Hallo zusammen,
ich habe gerade mein erstes kleines 'Projekt' in C# begonnen; es handelt sich um eine ASCII-Tabelle. Wer die GExperts für Delphi kennt, dem wird die Tabelle vielleicht bekannt vorkommen.
Da ich vermeiden möchte, mir von Anfang an einen schlechten Stil oder ähnliches anzueignen, würde ich mich freuen, wenn versierte Leute sich meine Sourcen einmal anschauen, und sich dazu äußern würden.
Dabei bitte ich darum, das Augenmerk nicht auf designtechnische Aspekte wie Schriftgröße, Farbe etc. zu legen, sondern ausschließlich auf den Code. Auch, wie man die Source-Dateien besser in Ordnern strukturiert verwalten kann etc.
Vielen Dank für Eure Unterstützung.
(Sourcecode ist im Zip enthalten)
Gruß
s-sharp
Hallo!
Habe die Sourcen gerade mal grob überflogen.
Das du region verwendest, ist schon mal nicht verkehrt.
Auch dokumentierst du bereits sehr viel, allerdings solltest du wenn möglich immer die XML-Dokumentation verwenden (3x /) und nur im eigentlichen Code // verwenden. Visual Studio belohnt dies damit, dir diese Dokumentation bei Verwendung des jeweiligen Elements anzuzeigen.
Als hilfreiches Werkzeug zur Dokumentation kann ich nur GhostDoc empfehlen, damit macht dokumentieren richtig Spaß.
Ansonsten finde ich den Stil schon ganz OK.
Nobody is perfect. I'm sad, i'm not nobody 🙁
Hallo und vielen Dank für Deine Antwort!
Auch dokumentierst du bereits sehr viel, allerdings solltest du wenn möglich immer die XML-Dokumentation verwenden (3x /) und nur im eigentlichen Code // verwenden.
Habe ich nachgeholt.
Visual Studio belohnt dies damit, dir diese Dokumentation bei Verwendung des jeweiligen Elements anzuzeigen.
Tolle Sache 👍
Als hilfreiches Werkzeug zur Dokumentation kann ich nur GhostDoc empfehlen, damit macht dokumentieren richtig Spaß.
Habe ich bereits im Einsatz, und nimmt einem wirklich einiges an Tipparbeit ab =)
Ansonsten finde ich den Stil schon ganz OK.
Das freut mich.
Aber es muss doch noch mehr geben, was nicht optimal gelöst ist 🤔
Ich hoffe auf weiteres Feedback. 🙂
Gruß
s-sharp
Hallo,
//ASCIIZeichen
public string character;
//Hint
public string hint;
Öffentliche Felder sollten nicht verwendet werden. Ersetze diese durch Eigenschaften.
CreateFont: //Marke setzen
try
{
//Font mit Style hinter aktuellem Styleindex erzeugen
font = new Font(name, size, (FontStyle)styles[styleindex]);
}
//wenn es knallen sollte, weil diese Schriftart diesen Style nicht unterstützt
catch (ArgumentException)
{
//setzen wir den Styleindex um eins hoch
styleindex++;
//und lassen das Spiel von vorne beginnen
goto CreateFont;
}
1.) Goto sollte man nicht verwenden. (while-Schleife wenn möglich)
2.) Hier wird IMHO try/catch zum steuern des Programmflusses eingesetzt.
Versuche den "Knall" vorher auszuschließen. Dass selbe gilt für Zeile 76 bis 92 in
sfx.ASCIIChart.Connect. Hier sollte versucht werden eine andere Lösung zu finden.
Mehr dazu hier.
Natürlich habe ich den Code jetzt nur überflogen und sicherlich nicht bis ins letzte Detail analysiert und verstanden. Möglicherweise hast du berechtigte Gründe die Sachen so zu Lösen. Ich habe auch keinen blas
sen Schimmer von Add-In Entwicklung.
Ansonsten sieht der Code sehr gut aus, und ist ungewohnt gut dokumentiert.
Gruss
tscherno
To understand recursion you must first understand recursion
Hallo, auch Dir vielen Dank für das Feedback!
Öffentliche Felder sollten nicht verwendet werden. Ersetze diese durch Eigenschaften.
Okay, habe die beiden Felder nun gekapselt.
1.) Goto sollte man nicht verwenden. (while-Schleife wenn möglich)
2.) Hier wird IMHO try/catch zum steuern des Programmflusses eingesetzt.
Versuche den "Knall" vorher auszuschließen. Dass selbe gilt für Zeile 76 bis 92 in
sfx.ASCIIChart.Connect. Hier sollte versucht werden eine andere Lösung zu finden.
Tja, an der Stelle stand ich vor einem Problemchen.
Ich habe dynamisch Font-Objekte erzeugt, und im Konstruktor den Regular-Schriftschnitt übergeben. Leider unterstützen den nicht alle Schriftarten, so dass es unter Umständen geknallt hat. Ich weiß nicht, wie ich im Voraus überprüfen soll, ob die Schriftart den Schnitt unterstützt, so dass ich es über die Exceptions geregelt habe.
Dass selbe gilt für Zeile 76 bis 92 in sfx.ASCIIChart.Connect.
Die Connect.cs-Datei wird automatisch von der IDE angelegt 😉
Gruß
s-sharp
So, ich habe nun den Weg über 'goto' durch eine entsprechende Schleife ersetzt.
/// <summary>
/// Erzeugt eine neue Schriftart unter Berücksichtigung, ob die Schriftart den zu setzenden Schriftschnitt unterstützt
/// </summary>
/// <param name="name">Schriftname</param>
/// <param name="size">Schriftgröße</param>
void CreateFont(string name, int size)
{
//ggf. bereits vorhandene Schriftart zerstören
if (font != null)
font.Dispose();
//ein Array mit sämtlichen Werten der FontStyles-Enum anlegen
int[] styles = new int[] { 0, 1, 2, 4, 8 };
//aktuellen Index auf 0 setzen
int styleIndex = 0;
//solange die Schriftart nicht mit dem Style instanziiert werden kann, Style wechseln und neu versuchen
do
{
try
{
//versuchen, Font mit Style hinter aktuellem Styleindex zu erzeugen
font = new Font(name, size, (FontStyle)styles[styleIndex]);
}
//sollte es knallen
catch (ArgumentException)
{
//setzen wir den Styleindex um eins hoch
styleIndex++;
//und das vorhandene Objekt auf null
font = null;
}
} while (font == null);
}
Schöner wäre es natürlich in der Tat, wenn man vorher wüsste, ob die zu erzeugende Schriftart den entsprechenden Schriftschnitt unterstützt, oder nicht.
Leider bin ich diesbezüglich noch immer nicht fündig geworden 🙁
Gruß
s-sharp
Hallo s-sharp,
vorigen Beitrag nur kurz überflogen, deshalb kann ich auch verkehrt liegen:
wenn
font = new Font(name, size, (FontStyle)styles[styleIndex]);
funktioniert, ist es dann keine Endlos-Schleife?
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Hallo,
wenn
font = new Font(name, size, (FontStyle)styles[styleIndex]);funktioniert, ist es dann keine Endlos-Schleife?
nein, da sie ja nur solange ausgeführt wird, solange mein font-Objekt gleich null ist.
Wenn die Instanziierung erfolgreich war, ist es das logischerweise nicht mehr 😉
Gruß
s-sharp
Hallo s-sharp,
hast recht 🤔 Ich hab da irgendwie immer eine umgekehrte Logik in meinem Kopf, ich fall von 10x bestimmt 7x drauf rein 😜
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
//aktuellen Index auf 0 setzen int styleIndex = 0;
ist nicht böse gemeint, aber solche Kommentare sind unnötig. Wenn man sich nur den Quellcode anschaut sieht man, das der Index (wahrscheinlich von einer Auflistung Styles) auf 0 gesetzt wird. Das zu dokumentieren halte ich eher für Zeitverschwendung. Es reicht in vielen Fällen aus, nur die Funktion und derren Argumente zu Kommentieren - am besten über ///
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hallo,
//aktuellen Index auf 0 setzen int styleIndex = 0;ist nicht böse gemeint, aber solche Kommentare sind unnötig. Wenn man sich nur den Quellcode anschaut sieht man, das der Index (wahrscheinlich von einer Auflistung Styles) auf 0 gesetzt wird.
mit 'böse' hat das nichts zu tun. Bin für jedes (!) Feedback dankbar.
Ich gebe Dir hier natürlich vollkommen recht; der Kommentar ist hier - normalerweise - absolut nicht notwendig.
Es ist nur so, dass ich gerade erst anfange, mich mit C#, generell mit C-basierten Sprachen, zu beschäftigen.
Bei mir dauert es zugegebenermaßen immer etwas länger, bis es 'klick' macht, und daher habe ich für mich beschlossen, zu Beginn alles zu kommentieren, um ggf. einen ganzen Programmabschnitt nur durch lesen der Kommentare nachvollziehen zu können - das hat mir in der Vergangenheit sehr geholfen, und ich hoffe, dass es das auch bei C# tut 😉
Das zu dokumentieren halte ich eher für Zeitverschwendung.
Nun, Zeitverschwendung würde ich es nicht nennen - es ist einfach nur unnötig und trägt nicht gerade zur guten Lesbarkeit des Codes bei 😉
Es reicht in vielen Fällen aus, nur die Funktion und derren Argumente zu Kommentieren - am besten über ///
In dem Punkt, muss ich Dir leider widersprechen - zumindest dann, wenn Du mit 'vielen' nahezu 'alle' meinst.
Ich entwickle hauptberuflich im Team (mit Delphi) an einer modularen Anwendung, die einige Millionen Zeilen Code umfasst (nur im Client-Bereich).
Da bei solchen Dimensionen nicht jeder jeden Bereich kennen kann, ist eine ausführliche Dokumentation sämtlicher Funktionalitäten unabdingbar, gerade deshalb, weil es sich um eine branchenspezifische Software aus dem Finanzwesen handelt.
Muss jemand für einen Kollegen einspringen, wäre es ziemlich aua, wenn der über eine schlecht, oder gar unkommentierte Funktion stolpern würde.
Und ich muss auch für mich selber sagen, dass es mir im Nachhinein oftmals hilft, Sachen schneller ins Gedächtnis zuück zu rufen, wenn ich mir gut kommentierte Methoden anschaue, gerade aus den Bereichen, an denen man nicht tagtäglich herumwerkelt.
Gruß
s-sharp
Hallo zusammen,
//aktuellen Index auf 0 setzen int styleIndex = 0;ist nicht böse gemeint, aber solche Kommentare sind unnötig. Wenn man sich nur den Quellcode anschaut sieht man, das der Index (wahrscheinlich von einer Auflistung Styles) auf 0 gesetzt wird. Das zu dokumentieren halte ich eher für Zeitverschwendung. Es reicht in vielen Fällen aus, nur die Funktion und derren Argumente zu Kommentieren - am besten über ///
auch ich kommentiere solche "unnötigen" Zeilen, warum? Weil ich denke, dass es die Lesbarkeit erhöht, weil wenn ich fremden Code überfliege zunächst nur die Kommentarzeilen lese (auch farblich durch Syntaxhiglighting getrennt). Und wenn mir die gesamte Logik nur durch Kommentare ersichtlich ist ohne Codezeilen zu lesen, dann erscheint mir das angenehmer.
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Ich persönlich versuche Funktionen und Methoden so smart wie möglich zu halten (lieber 20 einzel Funktionen, als 2000 Zeilen Code). Jede Funktion mit sprechendem Namen und Kommentare für die Funktion selbst sowie die Argumente.
Mit Delphi hab ich nie wirklich gearbeitet aber selbst in purem C reicht es meist aus, nur die Funktion zu Kommentieren
@Norman-Timo
Bei mir ist es eher andersrum, ich überlese meist Kommentare und versuche den Code selbst zu lesen und zu verstehen. Das klappt nicht immer Zeilenweise aber doch Blockweise
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Ich persönlich versuche Funktionen und Methoden so smart wie möglich zu halten (lieber 20 einzel Funktionen, als 2000 Zeilen Code). Jede Funktion mit sprechendem Namen und Kommentare für die Funktion selbst sowie die Argumente.
(Smart != kurz) zumindest nicht pauschal.
Natürlich versuche auch ich, kompakte Funktionen zu erstellen.
Hast Du aber eine Methode mit komplizierten Berechnungen, wäre die Aufsplittung oftmals kontraproduktiv.
Bei mir ist es eher andersrum, ich überlese meist Kommentare und versuche den Code selbst zu lesen und zu verstehen. Das klappt nicht immer Zeilenweise aber doch Blockweise
Du hast weiter oben das Argument 'Zeitverschwendung' gebracht. Im Hinblick auf diesen Kommentar widersprüchlich.
Wenn ich einen Defect im Code eines Kollegen beheben muss, dann möchte ich die Stelle an der es hakt auf Anhieb finden, und nicht erst lange danach suchen müssen - das ist Zeitverschwendung 😉
Eine generelle Aussage lässt sich hier aber sowieso nicht treffen. Der eine mag es so, der andere so 😉
Ich möchte jetzt auch ehrlich gesagt keine Grundsatzdiskussion zum Thema 'Wie kommentiere ich richtig' führen 😉
Gruß
s-sharp
Ich habe das Projekt mal umgeschrieben.
Es läuft nun nicht mehr als VS-AddIn, sondern als eigenständige Anwendung.
Da keine Interaktion mit der IDE notwendig ist, lässt sich das Ganze auch gut standalone als externes Tool einbinden und wird so vielleicht auch für Express-Nutzer interessant.
(und es lässt sich so wesentlich einfacher debuggen 😄)
Vielleicht hat ja jemand Verwendung dafür.
Gruß
s-sharp