General

Names should be related to the function of the identifier.

Do not use one or two-letter names – even loop variables should express what is iterated.

Do not use short abbreviations to distinguish names used together.

Abbreviations are always uppercase, e.g. MVO, 2D.

Identifiers (parameters, variables)

lowerCamelCase

Starts with a lowercase letter, every new word should begin with an uppercase letter.

Maximum length is 32 characters. Abbreviations at the start of the name can be uppercase, e.g. MVOValues.

Underscore ( _ ) in the middle of identifiers is allowed only to delimit a prefix that references something else (e.g. grouping meanings, constant values, subtype parameters). Use at most one _ in a name.

You should use a prefix in generally used variable names to denote general categories. This can spare time when someone needs to find out the type of a variable or parameter. Do not forget to replace the prefix if you change the type of a variable.

Prefix	Meaning	Example
i	general integer identifier / index / option set	iRiser iHandleType
n	countable integer value / amount of something / size of array	nRisers
–	general float value (length)	frameWidth
x / y / z w / h / d	position along an axis When separate locking or value ranges are not needed, use an array or dict instead of standalone x/y/z or w/h/d prefixed identifiers.	xRow2
b	boolean value	bHandrail
st	string type value	stPanelType
t	title of parameter group	tSurfaces
ang	angle value	angSlope
–	dictionary	doorDetlevel2D
pen	pen attribute	penContour penFillBg penFillPattern
linetype	line attribute	linetypeContour
filltype	fill attribute	filltypeMainBody
surf	surface attribute	surfCover
bmat	building material attribute	bmatTread
profile	profile attribute	profileRailing

One or two-letter names are allowed only in subroutines, e.g. a subroutine implementing a mathematical function where their meaning is very abstract.

Variables

_variable

Use a single underscore (_) prefix for a variable in a script, and double (__) for a variable declared and used only inside a subroutine section or for temporary variables.

Constants

CONSTANT

Altough GDL does not support constants, often-used fixed values (except trivial geometric values) should always be referenced by names. Write them as uppercase, so it is evident that they must not be overwritten.
Use constant variables for numeric identifiers used more than once:

• abstract integer values (options / choices / flags)

  ! OPENING_SYMBOL_DISPLAY
  SYMB_VISIBLE = 1
  SYMB_HIDDEN = 2
  SYMB_OVERHEAD = 3

• geometric constants
  FRAME_WIDTH = 0.05
• array indices (coordinate indices can be an exception when the array does not contain other data)
  railEdgeData[_iEdge][EDGE_SLOPEANGLE]

GLOBAL_VARIABLE

GDL global variables should also be treated as constants – they do not change during one execution of the script.

OPTION_VALUE

Fixed values representing choices (enum in other languages) should be grouped by a prefix.

String literals

"ASSOCLP_PARVALUE"

String values that have a meaning in a command (REQUEST, REQ, APPLICATION_QUERY, OPEN, INITADDONSCOPE, PREPAREFUNCTION, CALLFUNCTION) should be written uppercase.

Arrays

sashWidths[]

Array names should be plural.

Dictionaries

doorDetlevel2D.iLeaf

There are no special rules for dictionary names. Constant keys (except global variables’ keys) should be written in uppercase (e.g. EPS.ANGLE).
Variable keys do not need an _ prefix.

The names (and content) of keys should go from general to specific on deeper levels.

• The name of a key does not have to be unequivocal on its own, only read together with the ones before to avoid repetition. E.g.
  coverFill.pen instead coverFill.fillPen.
• The name of a key should be abstract, describing why / for what it is needed. E.g. cube.points.x instead cubeXCoords.
• The name of a key should be only one level of abstraction more specific than its parent. E.g. cube.points[].x, cube.points[].y instead cube.pointsX[] and cube.pointsY[].
• The name of the last key should contain a prefix (or just be an attribute prefix).
• The existence of optional keys should depend on the values of other keys – do not rely on using HASKEY for other than setting optional parameters of GDL commands

For geometric data, use the structures of BasicGeometry.

Parameters

descriptiveParameterName

Parameter names should be descriptive. Do not use abbreviations if possible.

Parameter names are case-insensitive in the script, but the content of GLOB_MODPAR_NAME as a string is case-sensitive.

For helper technical parameters (e.g. used for other parameters’ calculation or comparison), use stored suffix/prefix instead of temp if they can be written back to another parameter.

Subtype parameters

gs_nTurn

The child library parts automatically inherit all parameters of the parent in the subtype hierarchy. Parameters are identified by their name, so inherited and original parameters can have the same name. It is the responsibility of the library author to avoid conflicts.
Subtype parameters can be prefixed with abbreviated identifiers. Do not build deep hierarchical naming structures, a library part has only one parameter list without hierarchy.

• ac_ is reserved for parameters read/written by Archicad.
• gs_, ifc_, MEP_ is used by Graphisoft. Check the standard Library subtype templates for the complete list.
• FM_ is used by ArchiFM.

The subtype prefix should be used before any type prefix, e.g. gs_bFills.

String identifiers

UpperCamelCase

Starts with an uppercase letter, every new word should start with an uppercase letter.

Subroutine and group names

DrawSash

Subroutine names should start with a verb: Calc, Get, Draw, Call, etc…
Do not use space because it makes double-click selection and whole-word search harder. Do not use _ instead of spaces.

Library parts, subtypes, images, misc. filenames, attributes

Door with Transom

Use spaces between words, capitalize principal words – aka. Title Case.

Subtype names should end with “Template” to avoid name conflicts.

Image names should include a hint of their function (“Icon“, “Texture“, …).

Do not use extensions when referring to filenames; the Library Manager can handle it without extensions. Do not use the same name for different types of files.

Macros

DetlevelDWFunctionMacro

As these are often written in the script, do not use _ and space. Capitalize each word, and give a descriptive name.

HSF folder structure

A folder should contain either only subfolders or only libparts. Macros and placeable libparts should be in separate folders. Group libparts in a strong hierarchy, a folder should contain no more than about 20 direct subfolders. Folder names should be short but descriptive (without abbreviations), the maximum path length is 255 characters for platform compatibility reasons.

Parameter meanings

ElectricSymbols_FillPen

Use prefixes to group attributes of a libpart or identify a group of libparts. These prefixes should be unabbreviated UpperCamelCase on their own. Use suffixes to indicate parameter type. Use “Length_” for SI-imperial conversion. Do not use attribute values in the name.

Keywords

lowercase

Keywords, commands, and functions should be written consistently in lowercase. The exception is the PI constant.

del ntr()
for i = 1 to nsp