Difference between revisions of "DoDont/de"

From Free Pascal wiki
Jump to navigationJump to search
m
m (extended the translation; The item 'bout hungarian notation had in the translation a totally inverted meaning)
Line 2: Line 2:
  
 
= Die richtige und die falsche Art mit Pascal zu programmieren =
 
= Die richtige und die falsche Art mit Pascal zu programmieren =
 +
 
Das sind alles selbst erarbeitete Hinweise zur Programmierung.<br>
 
Das sind alles selbst erarbeitete Hinweise zur Programmierung.<br>
−
Ich habe die richtige und die unrichtige Art der Programmierung auf die harte Tour gelernt, und zwar, indem ich die falschen Dinge zuerst gemacht habe.<br>
+
Ich habe die richtige und die unrichtige Art der Programmierung auf die harte Tour gelernt, und zwar, indem ich die falschen Dinge zuerst gemacht habe.
−
<br>
+
 
−
== Die richtige Art zu programmieren ==
+
== Richtig ==
−
# Verwende während der Entwicklung die Bereichsüberprüfungen des Compilers (Bereich, IO, Überlauf). Compilerschalter "-Crio"
+
 
−
# Verwende von Zeit zu Zeit heaptrace, um zu sehen, ob Sie irgendwelche Speicherlecks haben. Compilerschalter "-ghl"
+
# Verwenden Sie während der Entwicklung die '''Bereichsüberprüfungen''' des Compilers (Bereich, IO, Überlauf). Compilerschalter "-Crio"
−
# Teile grosse Units in mehrere kleinere Units auf. Grosse Units sind fast immer ein Zeichen von schlechtem Programmdesign.
+
# Verwenden Sie von Zeit zu Zeit '''heaptrace''', um zu sehen, ob Sie irgendwelche Speicherlecks haben. Compilerschalter "-ghl"
−
# Versehen Sie Ihre Variablen und Unterprogramme mit sprechenden Namen. Verfolgen Sie bei der Namensgebung konsequent einen einheitlichen Stil.
+
# Teilen Sie riesige Units in mehrere kleinere Units auf. Grosse Units sind '''fast immer''' ein Zeichen von schlechtem Programmdesign.
−
# Es ist allgemein üblich, für die Namen der Identifier sinnvolle Namen zu verwenden
+
# Teilen Sie riesige [[Function|Funktionen]] / [[Procedure|Prozeduren]] / [[Method|Methoden]] auf. Große Funktionen/Prozeduren/Methoden sind ein Zeichen schlechten Designs oder schlechter Logik. Eine gute Faustregel: Keine Funktionen, Prozeduren oder Methoden länger als eine gedruckte Seite (ungefähr 55 Zeilen) oder, besser noch, als eine Bildschirmseite. Das was auf eine Seite (des Bildschirms oder des Ausdruckes) passt, werden Sie vermutlich besser verstehen als das, was Sie nicht sehen oder wozu Sie erst umblättern müssen.
−
# Verwenden Sie bei den Variablennnamen so etwas wie die "ungarische Notation" (ein Präfix zeigt an, um welchen Datentyp es sich handelt.)
+
# Versehen Sie Ihre Variablen und Unterprogramme mit '''sprechenden Namen'''. Verfolgen Sie bei der Namensgebung konsequent einen einheitlichen Stil.
−
# Arbeiten Sie beim Codieren mit Einrückungen. Dies macht den Code lesbarer und verständlicher.
+
# Es ist allgemein üblich, sinnvolle Namen für die Bezeichner zu verwenden. Dies gehört in Pascal noch häufiger zum gute Ton als in anderen Sprachen. Ausgennommen davon sind die Variablennamen i, j und k die durchwegs bei FOR-Schleifen als Kontrollvariablen oder als Schleifenzähler eingesetzt werden. Speziell auch bei Schleifen, die nur zur Initialisierung eines Arrays oder zu Anzeigen seiner Elemente dienen. Deshalb sind Schleifenvariablen immer nur lokal gültig.
−
# Die einzig wahre Programmiersprache für Ihre Arbeit ist Pascal.
+
# Die "ungarische Notation" (ein Präfix zeigt den Datentyp der Variablen) wird heute schief angesehen. Pascal hat eine hinreichend starke Typisierung. Ausgenommen davon sind vielleicht die Komponenten auf einem Lazarus-Form, z. B. edMeinName für ein Eingabefeld und labMeinName für das zugehörige Label.
−
<br>
+
# Arbeiten Sie beim Codieren mit Einrückungen. Bleiben Sie bei einem einzigen Einrückungsstil. Dies macht den Code lesbarer und verständlicher.
−
== Die falsche Art zu programmieren ==
+
# Die einzig wahre Programmiersprache für eine Aufgabe ist die, mit der Sie Ihre Arbeit begonnen haben. Und das ist Pascal!
−
# Nimm alle Punkte aus dem obigen (richtigen) Abschnitt und verkehre sie in ihr Gegenteil.
+
 
−
# Zweifle am Leistungsumfang von Pascal.
+
== Falsch ==
−
# Verwenden Sie den Compilerschalter "-Ct" (stack check) unter Windows 32 Bit niemals im Zusammenhang mit Threads.
+
 
 +
# Nehmen Sie alle Punkte aus dem obigen (richtigen) Abschnitt und verkehre sie in ihr Gegenteil.
 +
# Zweifeln Sie am Leistungsumfang von Pascal.
 +
# Verwenden Sie niemals den Compilerschalter "-Ct" (stack check) unter Windows 32 Bit im Zusammenhang mit Threads.
 
# Verwenden Sie niemals für Argumente und Datenfelder die selben Namen.
 
# Verwenden Sie niemals für Argumente und Datenfelder die selben Namen.
−
<br>
+
 
−
<br>
 
  
 
{{AutoCategory}}
 
{{AutoCategory}}

Revision as of 17:39, 15 September 2013

│ Deutsch (de) │ English (en) │ français (fr) │

Die richtige und die falsche Art mit Pascal zu programmieren

Das sind alles selbst erarbeitete Hinweise zur Programmierung.
Ich habe die richtige und die unrichtige Art der Programmierung auf die harte Tour gelernt, und zwar, indem ich die falschen Dinge zuerst gemacht habe.

Richtig

  1. Verwenden Sie während der Entwicklung die Bereichsüberprüfungen des Compilers (Bereich, IO, Überlauf). Compilerschalter "-Crio"
  2. Verwenden Sie von Zeit zu Zeit heaptrace, um zu sehen, ob Sie irgendwelche Speicherlecks haben. Compilerschalter "-ghl"
  3. Teilen Sie riesige Units in mehrere kleinere Units auf. Grosse Units sind fast immer ein Zeichen von schlechtem Programmdesign.
  4. Teilen Sie riesige Funktionen / Prozeduren / Methoden auf. Große Funktionen/Prozeduren/Methoden sind ein Zeichen schlechten Designs oder schlechter Logik. Eine gute Faustregel: Keine Funktionen, Prozeduren oder Methoden länger als eine gedruckte Seite (ungefähr 55 Zeilen) oder, besser noch, als eine Bildschirmseite. Das was auf eine Seite (des Bildschirms oder des Ausdruckes) passt, werden Sie vermutlich besser verstehen als das, was Sie nicht sehen oder wozu Sie erst umblättern müssen.
  5. Versehen Sie Ihre Variablen und Unterprogramme mit sprechenden Namen. Verfolgen Sie bei der Namensgebung konsequent einen einheitlichen Stil.
  6. Es ist allgemein üblich, sinnvolle Namen für die Bezeichner zu verwenden. Dies gehört in Pascal noch häufiger zum gute Ton als in anderen Sprachen. Ausgennommen davon sind die Variablennamen i, j und k die durchwegs bei FOR-Schleifen als Kontrollvariablen oder als Schleifenzähler eingesetzt werden. Speziell auch bei Schleifen, die nur zur Initialisierung eines Arrays oder zu Anzeigen seiner Elemente dienen. Deshalb sind Schleifenvariablen immer nur lokal gültig.
  7. Die "ungarische Notation" (ein Präfix zeigt den Datentyp der Variablen) wird heute schief angesehen. Pascal hat eine hinreichend starke Typisierung. Ausgenommen davon sind vielleicht die Komponenten auf einem Lazarus-Form, z. B. edMeinName für ein Eingabefeld und labMeinName für das zugehörige Label.
  8. Arbeiten Sie beim Codieren mit Einrückungen. Bleiben Sie bei einem einzigen Einrückungsstil. Dies macht den Code lesbarer und verständlicher.
  9. Die einzig wahre Programmiersprache für eine Aufgabe ist die, mit der Sie Ihre Arbeit begonnen haben. Und das ist Pascal!

Falsch

  1. Nehmen Sie alle Punkte aus dem obigen (richtigen) Abschnitt und verkehre sie in ihr Gegenteil.
  2. Zweifeln Sie am Leistungsumfang von Pascal.
  3. Verwenden Sie niemals den Compilerschalter "-Ct" (stack check) unter Windows 32 Bit im Zusammenhang mit Threads.
  4. Verwenden Sie niemals für Argumente und Datenfelder die selben Namen.
Retrieved from "http://wiki.freepascal.org/index.php?title=DoDont/de&oldid=72378"