Difference between revisions of "DesignGuidelines"

From Lazarus wiki
Jump to navigationJump to search
(Updated.)
m (Categorisation)
 
(30 intermediate revisions by 11 users not shown)
Line 1: Line 1:
 +
{{DesignGuidelines}}
 +
 
== Coding Guidelines for Lazarus ==
 
== Coding Guidelines for Lazarus ==
  
'''This is for lazarus developers:'''
 
  
 
;Coding style:
 
;Coding style:
* Since one style is easier to read, Lazarus follows the Borland Coding style guide lines. Of course, almost anyone will find some points there, that are arguable less readable than other styles. That's ok, just try to follow at least 90%.
+
* Since one style is easier to read, Lazarus follows the [http://edn.embarcadero.com/article/10280 CodeGear Coding Style Guide] lines. Of course, almost anyone will find some points there, that are arguably less readable than other styles. That's OK, just try to follow at least 90%. See the LCL for examples.
* Try to avoid unit circles. This makes it easier to navigate and when unit is growing allows to split it.
+
* Try to avoid unit cycles (uses section in implementation sections). Reasons: 1. FPC has problems with them. 2. This allows to split units and packages when they have grown big.
* Minimize the number of calls from Interfaces to LCL, when performing an action requested by the LCL.
+
* Minimize the number of calls from Interfaces to LCL, when performing an action requested by the LCL. The interfaces only notify the LCL, never force something. The LCL decides.
 
+
* Naming convention: see [[Nomenclature]]
 +
* All code must work with all checks (range, I/O, overflow, stack) on. Apart from the fact that this helps debugging, some users put these checks into their fpc.cfg, so they are applied to whole Lazarus - including packages and examples.
 +
* Names in comments: Comments should help the reader. They are not for the glory of the writer. You can add a name if you are the maintainer aka get the bug reports assigned or if the name is a good search term to find help on this topic.
  
 
;New files:
 
;New files:
 
* Every file should start with a header containing the license and a few lines describing the content.
 
* Every file should start with a header containing the license and a few lines describing the content.
 
+
* Pascal sources should have lowercase filenames (.pas, .pp, .inc, .lfm, .lrs). You can use CamelCase for unit names.
  
 
;Include files:
 
;Include files:
 
* should start with the {%MainUnit } directive
 
* should start with the {%MainUnit } directive
 
  
 
;Packages:
 
;Packages:
 
* should have an .lpl entry in packager/globallinks/
 
* should have an .lpl entry in packager/globallinks/
 +
* should have an author, description and license
  
 +
;Main Menu Items:
 +
* Should have a key in keymapping.pp
  
;Dialogs (modal forms):
+
-----
* Close on Escape (if key not used otherwise)
+
''The authoritative version can be found in [http://svn.freepascal.org/svn/lazarus/trunk/docs/DesignGuidelines.txt svn]. Proposals for improvement can be added to talk page (discussion)''.
* Define default button and Return activates it (if key not used)
 
* Medium to complex dialogs should be resizable and size is stored
 
  
 +
=== GUI ===
  
;Main Menu Items:
+
See [[GUI design guidelines]]
* Should have a key in keymapping.pp
+
 
 +
== See also ==
  
 +
* Free Pascal (FPC) coding standard (used for the compiler and other FPC code): [[Coding style]]
  
-----
+
[[Category:FPC]]
''Latest version can be found in [http://www.freepascal.org/cgi-bin/viewcvs.cgi/projects/lazarus/docs/DesignGuidelines.txt?rev=HEAD cvs]. Proposals for improvement can be added to talk page (discussion)''.
+
[[Category:Lazarus]]
 +
[[Category:Coding style]]
 +
[[Category:Coding guidelines]]
 +
[[Category:Guidelines]]

Latest revision as of 08:09, 15 April 2020

Deutsch (de) English (en) español (es) français (fr) 日本語 (ja) 한국어 (ko) português (pt) русский (ru)

Coding Guidelines for Lazarus

Coding style
  • Since one style is easier to read, Lazarus follows the CodeGear Coding Style Guide lines. Of course, almost anyone will find some points there, that are arguably less readable than other styles. That's OK, just try to follow at least 90%. See the LCL for examples.
  • Try to avoid unit cycles (uses section in implementation sections). Reasons: 1. FPC has problems with them. 2. This allows to split units and packages when they have grown big.
  • Minimize the number of calls from Interfaces to LCL, when performing an action requested by the LCL. The interfaces only notify the LCL, never force something. The LCL decides.
  • Naming convention: see Nomenclature
  • All code must work with all checks (range, I/O, overflow, stack) on. Apart from the fact that this helps debugging, some users put these checks into their fpc.cfg, so they are applied to whole Lazarus - including packages and examples.
  • Names in comments: Comments should help the reader. They are not for the glory of the writer. You can add a name if you are the maintainer aka get the bug reports assigned or if the name is a good search term to find help on this topic.
New files
  • Every file should start with a header containing the license and a few lines describing the content.
  • Pascal sources should have lowercase filenames (.pas, .pp, .inc, .lfm, .lrs). You can use CamelCase for unit names.
Include files
  • should start with the {%MainUnit } directive
Packages
  • should have an .lpl entry in packager/globallinks/
  • should have an author, description and license
Main Menu Items
  • Should have a key in keymapping.pp

The authoritative version can be found in svn. Proposals for improvement can be added to talk page (discussion).

GUI

See GUI design guidelines

See also

  • Free Pascal (FPC) coding standard (used for the compiler and other FPC code): Coding style