RADProgrammer Style Guide Naming Conventions

Identifiers

Identifiers should use the Pascal Case capitalization convention implemented in English with ASCII letters and digits only.

Do not use underscores or hyphens to differentiate words. Note: closed-form compound words should normally only have the first letter capitalized while open and hyphenated compound words should be expressed in Pascal Case form.

You should not normally refer to a particular data type in a name, but you should clarify measurements (such as naming a parameter TimeOutSeconds in order to clearly define the length of the timeout.)

Avoid abbreviations in all identifier naming unless commonly utilized.

Header translations and other external references should follow the conventions used in the external source file.

Historic Naming Conventions Maintained:

• Class names should begin with a capital T as in TMyExampleClass
• Exception class names should begin with a capital E as in EInvalidConversion
• Interface names should begin with a capital I as in IMyExampleInterface
• Custom Attributes class names are not prefixed with any character and always end with the word Attribute as in MyExampleAttribute (Note the trailing Attribute portion of the name is optional when referenced in code such as [MyExample]
• Pointer type aliases should begin with a capital P as in PInteger
• Field names should begin with a uppercase F as in FMyExampleField:Integer
• Event handler names begin with the word On as in OnMyExampleEvent
• Event execution method names start with Do followed by the event name as in DoMyExampleEvent

Custom Rules

• Enumerated Types should follow Pascal Case convention without a prefix and always referenced later in code outside its parent unit via its fully qualified name.

• Constants should be defined within a parent class and not have a prefix and always referenced later in code outside its parent unit via its fully qualified name. If constants need to be defined outside of a class, use UpperCase declarations

• (Optional) Method Parameters should begin with a lowercase 'a' as in aMyExampleParamter:Integer; (Parameter prefixes will be dropped when the compiler can provide a warning for a potential conflict between a parameter name and another identifier in scope.) Parameter names should not be prefixed if specified/documented in externally referenced APIs. (In 2023 started migration from 'p' to 'a' prefix mainly to keep p available for pointer prefix historical use which has always been a point of contention of using p prefix but also to get closer to the capital A prefix used by Delphi's auto-generated code. Preference is a lowercase prefix but can use uppercase A if desired.)

• (Deprecated) Local Variables should begin with a lowercase 'v' as in vMyExampleVariable:Integer; unless they are commonly used and easily recognizable short names (such as counter variables i, j and using h for handle.)

• Class Constructors/Destructors should be named CreateClass and DestroyClass

• Test Classes are named starting with the name of the class they are testing and ending with Test as in TMyExampleClassTest

• Versioned Interfaces are suffixed with a numeric version starting with 2 for the second version as in IMyExampleInterface2

• Components Dropped On Forms require a descriptive name if referenced in code (either manually or via auto-generated events) and never be left as the default auto-generated name (i.e., no references to Button1 in code.) Also, do not use Hungarian notation for component names such as butDeleteFile You can include the intention or kind of component within the name via an appropriate suffix such as DeleteFileButton

RADProgrammer Code

• Visual Component custom component class names should be prefixed with TRad
• Unit names should be prefixed with rad immediately followed by a project and unit identifiers as in radStyleGuide.MyExample.pas
  • Platform specific implementations should be suffixed with a platform designator as in radStyleGuide.MyExample.iOS.pas

Pascal Case Conversions

To aid converting some phrases to Pascal Case, use this process:

• Convert the phrase to plain ASCII and remove any apostrophes
• Replace embedded punctuation with spaces
• Separate the phrase into single-spaced words
• Uppercase the first character of each word and lowercase all other characters
• Join all words into a single identifier by stripping all spaces

Naming Specific Items

• Arrays and Lists since these hold multiple values, pluralizing the variable name makes sense and use the singular form as the variable name when iterating.

• Booleans should be positively named rather than negative to prevent double negatives like if not IsNotActive with few exceptions (e.g. optional values which always default to false) Common prefixes for Booleans include is, has, can, and should

• Method names are typically verbs or verb phrases as in "Action"+"Resource" (such as CalculateTotal)

• Properties are often named as nouns, noun phrases or adjectives of the data being referenced