Difference between revisions of "DesignGuidelines/de"
From Lazarus wiki
Jump to navigationJump to search| Line 4: | Line 4: | ||
;Programmierungsstil: | ;Programmierungsstil: | ||
| − | * Weil ein Stil einfacher zu lesen ist, folgt Lazarus den Borland Coding Style Richtlinien. Natürlich wird beinahe jeder einige Punkte finden, | + | * Weil ein Stil einfacher zu lesen ist, folgt Lazarus den Borland Coding Style Richtlinien. Natürlich wird beinahe jeder einige Punkte finden, die zweifelhaft weniger lesbar sind als andere Stile. Das ist ok, versuchen sie einfach wenigstens zu 90% zu folgen. |
| − | * Versuchen sie | + | * Versuchen sie, Unit Kreise zu vermeiden. Dies macht es einfacher zu navigieren und wenn die Unit anwächst, erlaubt es die Unit zu splitten. |
| − | * Minimieren sie die Anzahl der | + | * Minimieren sie die Anzahl der Aufrufe von den Schnittstellen zur LCL, wenn die Ausführung einer Aktion von der LCL angefordert wird. Die Schnittstellen benachrichtigen nur die LCL, niemals erzwingen sie etwas. Die LCL entscheidet. |
** Namenskonventionen: | ** Namenskonventionen: | ||
*** Anzeigen für TControl Nachfahren sollten CNxxx genannt werden. | *** Anzeigen für TControl Nachfahren sollten CNxxx genannt werden. | ||
| Line 27: | Line 27: | ||
;Dialoge (modale Formulare): | ;Dialoge (modale Formulare): | ||
| − | * | + | * Schließen mit Escape (wenn die Taste nicht anderweits verwendet wird) |
| − | * Definieren sie | + | * Definieren sie einen Vorgabe Button und Return aktiviert ihn (wenn die Taste nicht verwendet wird) |
* Mittlere bis komplexere Dialoge sollten größenveränderbar sein und die Größe wird gespeichert | * Mittlere bis komplexere Dialoge sollten größenveränderbar sein und die Größe wird gespeichert | ||
Revision as of 19:54, 28 September 2005
Programmierungsrichtlinien für Lazarus
Dies ist für Lazarus Entwickler:
- Programmierungsstil
- Weil ein Stil einfacher zu lesen ist, folgt Lazarus den Borland Coding Style Richtlinien. Natürlich wird beinahe jeder einige Punkte finden, die zweifelhaft weniger lesbar sind als andere Stile. Das ist ok, versuchen sie einfach wenigstens zu 90% zu folgen.
- Versuchen sie, Unit Kreise zu vermeiden. Dies macht es einfacher zu navigieren und wenn die Unit anwächst, erlaubt es die Unit zu splitten.
- Minimieren sie die Anzahl der Aufrufe von den Schnittstellen zur LCL, wenn die Ausführung einer Aktion von der LCL angefordert wird. Die Schnittstellen benachrichtigen nur die LCL, niemals erzwingen sie etwas. Die LCL entscheidet.
- Namenskonventionen:
- Anzeigen für TControl Nachfahren sollten CNxxx genannt werden.
- Namenskonventionen:
- Der ganze Code muß mit allen Kontrollen arbeiten (range, io, overflow, stack). Außerdem hilft dies beim Debuggen, einige Benutzer legen diese Kontrollen in ihrer fpc.cfg ab, daher finden sie Anwendung auf das gesamte Lazarus. Inklusive Packages und Beispiele.
- Neue Dateien
- Jede Datei sollte mit einem Header beginnen, der die Lizenz enthält und einige Zeilen, die den Inhalt beschreiben.
- Pascal Quellen sollten kleingeschriebene Dateinamen besitzen (.pas, .pp, .inc, .lfm, .lrs)
- Include Dateien
- Sollten mit der {%MainUnit } Direktive beginnen
- Packages
- Sollten einen .lpl Eintrag haben in packager/globallinks/
- Dialoge (modale Formulare)
- Schließen mit Escape (wenn die Taste nicht anderweits verwendet wird)
- Definieren sie einen Vorgabe Button und Return aktiviert ihn (wenn die Taste nicht verwendet wird)
- Mittlere bis komplexere Dialoge sollten größenveränderbar sein und die Größe wird gespeichert
- Hauptmenü Elemente
- Sollten einen Schlüssel in keymapping.pp haben
Die neueste Version ist zu finden in design. Verbesserungsvorschläge können zur talk page (discussion) hinzugefügt werden.
