Difference between revisions of "DoDont/de"

From Lazarus wiki
Jump to navigationJump to search
 
(8 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
= 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.
+
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 zu erst gemacht habe.
+
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.
  
== Right ==
+
== Richtig ==
  
#Use checks (Range, IO, Overflow) when developing. You can enable them with "-Crio" compiler switch.
+
# Verwenden Sie während der Entwicklung die '''Bereichsüberprüfungen''' des Compilers (Bereich, IO, Überlauf). Compilerschalter "-Crio"
#Use heaptrace from time to time to see if you have any memory leaks. Enable via "-ghl" compiler switch to get best result.
+
# Verwenden Sie von Zeit zu Zeit '''heaptrace''', um zu sehen, ob Sie irgendwelche Speicherlecks haben. Compilerschalter "-ghl"
#Split huge [[Glossary#Unit|units]]. Big units are ALMOST ALWAYS a sign of bad design or logic. (you know it's bad when you have unrelated constructs in one unit).
+
# Teilen Sie riesige Units in mehrere kleinere Units auf. Grosse Units sind '''fast immer''' ein Zeichen von schlechtem Programmdesign.
#Split huge [[Function|functions]] / [[Procedure|procedures]] / [[Method|methods]]. Big functions/procedures/methods are sign of bad design or logic. A good rule of thumb is to have no function, procedure or method longer than one printed page (about 55 lines) or, even better, one screen if you can. What you can visualize in one screen (or on one printed page, if you use printed listings) you can probably understand better than what you can't see or have to flip from page to page to read.
+
# 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.
#Name your variables/functions properly lest you will damn yourself with unmaintainable code. Be consistent in how you do things.
+
# Versehen Sie Ihre Variablen und Unterprogramme mit '''sprechenden Namen'''. Verfolgen Sie bei der Namensgebung konsequent einen einheitlichen Stil.
#It is commonplace to use meaningful identifier names. While every languages advises this, it is way more common in practice in Pascal. However, the variable names I, J and K are commonly used as general purpose FOR control variables and similar usage for loop counters, especially where the loop is only being used to initialize or display members of arrays. Loop variables must be local anyway.
+
# 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.  
#Hungarian notation ( a "prefix code" to indicate what the type of a variable is) is frowned upon (Pascal has strong enough typing). Except maybe for components on a Lazarus form. e.g. edsomething for an edit field and labsomething for the corresponding label etc
+
# 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.
#Stick with one identation style. Change only if you hadn't followed a standard style till then.
+
# Arbeiten Sie beim Codieren mit Einrückungen. Bleiben Sie bei einem einzigen Einrückungsstil. Dies macht den Code lesbarer und verständlicher.
#The only right language for the job is the one you started the work with. And that's [[Pascal]]!
+
# Die einzig wahre Programmiersprache für eine Aufgabe ist die, mit der Sie Ihre Arbeit begonnen haben. Und das ist Pascal!
  
== Wrong ==
+
== Falsch ==
  
#Put all points from Right section here and negate them.
+
# Nehmen Sie alle Punkte aus dem obigen (richtigen) Abschnitt und verkehre sie in ihr Gegenteil.
#Have doubts in Pascal.
+
# Zweifeln Sie am Leistungsumfang von Pascal.
#NEVER use -Ct (stack check) in Win32 with threads! There's a "feature" which can be a problem.
+
# Verwenden Sie niemals den Compilerschalter "-Ct" (stack check) unter Windows 32 Bit im Zusammenhang mit Threads.
#Don't name your arguments with names of fields. Even if they are private ie: FField and Field in argument.
+
# Verwenden Sie niemals für Argumente und Datenfelder die selben Namen.
 +
 
 +
{{AutoCategory}}

Latest revision as of 16:17, 17 September 2014

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.