Oxygene Code Style Guide

This document aims at providing a style guide for how to structure and format code written in the Oxygene language.

The guidelines laid out here are by no means mandatory, and an Oxygene developer may choose to adopt all, some, or none of the guidelines provided. However, our IDEs are designed to work best when code follows the guidelines, and we try to adhere to these guidelines for all code in Elements and its surrounding libraries, ourselves. Code submissions and pull requests for the open-source Elements libraries must meet these guidelines, as well.

Keywords

  • All keywords shall be used in their lowercase form.
  • Use the method keyword instead of procedure or function.
  • Use the block keyword instead of delegate, method, procedure or function, for Block declarations.
  • Use the namespace keyword instead of unit, at the beginning of a file.

Casing & Naming Conventions

While Oxygene is case insensitive, it by default preserves case and warns when identifiers differ in case between their declaration and use. These warnings should be avoided, and care should be taken to use the proper case. We recommend enabling Auto-Fix for case issues.

  • Again, all keywords shoul;d be lower case
  • Type names should use a PascalCase form, without the T prefix common in other Pascal dialects. Upper-case abbreviation prefixes should also be avoided where posisble. Use Namespaces instead.
  • Interface types should use an I prefix, followed by a PascalCased name.
  • Public type Members (that should exclude fields) should use PascalCase names unless the platform conventions for a single-platform project suggest otherwise.
  • Variables usually use a single-letter lower-case prefix, followed by a PascalCase name:
    • Fields should use an f prefix: fName
    • Local Variables should use an l prefix: lName
    • Parameters should use an a prefix: aName
    • Only loop Variables or very short-lived helpers variables may use short, lowercase names: i, x.

Code Block Structure

If an if uses a begin/end block, any connected else clause must also use begin/end, and vice versa. In other words, an if clause with a block should not be mixed with a single-statement else clause, or vice versa.

Bad:

if Something then
  DoThis
else begin
  DoThat;
  AndThisOtherThing;
end;

Better:

if Something then begin
  DoThis
end
else begin
  DoThat;
  AndThisOtherThing;
end;

The else should always start on a new line, never follow the end or the first statement.

If an if, else, for, while or similar statement does not uses a begin/end block, the then or do keyword should always be followed by a linebreak and the following statement should be indented in a new line.

if Something then exit;

Better:

if Something then 
  exit;

Statements with a begin/end block, should never be nested inside statements where the begin/end block, was omitted.

Bad:

if Something then
  if SomethingElse then
    for a in list do begin
      ...
    end;

Better:

if Something then begin
  if SomethingElse then begin
    for a in list do begin
      ...
    end;
  end;
end;

Spacing

Consistent spacing should bne used thru-out all code in a file.

Types spanning more than a single line should be preceded and succeeded by a single empty line, to separe them from their siblings. However there should be no empty line between the type keyword and the first type that follows it.

Single-line types (usually aliases, short enums, etc) bay be in a single block without spacing, of the types be,log logically together (e.g. several related enums).

Inside a Class (or Record) declaration, members should be spaced consistently. Single-line members (such as Properties, Fields, Events, or Methods w/o inline implementation) may be grouped logically, with individual groups separated by a single line.

Multi-line members should always be preceded and succeeded by a single emoty line; even if they are the first, last or only member in the current type oir visibility block.