Naming conventions


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)


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


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.

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



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.



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.



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)
  • geometric constants
    FRAME_WIDTH = 0.05
  • array indices (coordinate indices can be an exception when the array does not contain other data)


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


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

String literals


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



Array names should be plural.



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.



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


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


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

Subroutine and group names


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.



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


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, commands, and functions should be written consistently in lowercase. The exception is the PI constant.

del ntr()
for i = 1 to nsp