About

4D (4th Dimension) methods use a proprietary commenting style and type declaration syntax (C_TEXT, C_LONGINT, C_OBJECT) that no standard documentation generator understands. If your codebase lacks machine-readable DocBlocks, automated API docs become impossible, onboarding slows, and refactoring turns dangerous. This converter parses 4D parameter declarations ($1…$n), return values ($0), and inline comments, then emits compliant /** … */ DocBlock output with @param, @returns, and @description tags. It handles 15 native 4D types and preserves comment context.

The tool assumes one method per input block. Multi-method files should be split before conversion. Nested C_* declarations inside conditionals are extracted but flagged as conditional parameters. Edge case: unnamed parameters (bare $1 without a preceding C_* line) are typed as unknown.

Formulas

The converter applies a deterministic state-machine pass over each line of 4D source code. The core transformation rule maps 4D type declarations to DocBlock parameter tags:

C_TYPE($n) → @param {mappedType} $n − description

where C_TYPE is any 4D type keyword, $n is the parameter index (1…N), and mappedType is resolved from the type mapping table. Return values follow:

C_TYPE($0) → @returns {mappedType} description

Leading comment lines (// prefix) preceding any C_* declaration are collected into the @description field. The regex pattern for type extraction is:

match(/^\s*C_(\w+)\s*$(.+)$/i)

where capture group 1 yields the type name and group 2 yields the comma-separated variable list. Array declarations use a parallel pattern:

match(/^\s*ARRAY\s+(\w+)\s*$(.+)$/i)

Reference Data

4D Type Declaration	DocBlock Type	Description	Default Value
C_TEXT	string	Unicode text string	""
C_LONGINT	number	32-bit signed integer (−2³¹ to 2³¹−1)	0
C_REAL	number	64-bit IEEE 754 float	0.0
C_BOOLEAN	boolean	True/False flag	FALSE
C_POINTER	Pointer	Reference to any 4D object	NULL
C_OBJECT	Object	JSON-compatible object	NULL
C_COLLECTION	Collection	Ordered array of values	NULL
C_DATE	Date	Calendar date (no time)	00/00/00
C_TIME	Time	Duration in seconds from midnight	00:00:00
C_BLOB	Blob	Binary large object	NULL
C_PICTURE	Picture	Image data container	NULL
C_VARIANT	*	Any type (resolved at runtime)	undefined
C_INTEGER	number	16-bit signed integer (legacy)	0
C_COMP	number	64-bit integer (composite)	0
ARRAY TEXT	string[]	Array of text values	[]
ARRAY LONGINT	number[]	Array of 32-bit integers	[]
ARRAY REAL	number[]	Array of floats	[]
ARRAY BOOLEAN	boolean[]	Array of booleans	[]
ARRAY OBJECT	Object[]	Array of objects	[]
ARRAY POINTER	Pointer[]	Array of pointers	[]
ARRAY DATE	Date[]	Array of dates	[]
ARRAY PICTURE	Picture[]	Array of images	[]

Frequently Asked Questions

If a parameter variable like $1 appears in method body code but has no preceding C_TEXT, C_LONGINT, or other type declaration, the converter assigns the type * (any/unknown) in the DocBlock @param tag and appends a warning comment. This ensures the DocBlock is still structurally valid while flagging incomplete type information.

Yes. Lines beginning with // that appear before the first C_* declaration are concatenated into the @description field. Inline comments on the same line as a C_* declaration (after the closing parenthesis) are extracted and used as the parameter description in the corresponding @param tag. Block comments (/* ... */) are treated as description text.

4D allows declaring multiple variables in a single C_TEXT($1;$2;$3) statement using semicolons as separators. The converter splits on both ; and , delimiters, generating a separate @param entry for each variable. All share the same mapped type. Individual descriptions default to the parameter name unless an inline comment provides context.

Yes. Declarations like ARRAY TEXT($myArr;0) are parsed with a dedicated regex. The type maps to the array equivalent (e.g., string[]). The second argument (the size initializer, typically 0) is ignored in the DocBlock output since it is a runtime detail, not a type property.

4D uses $ prefix for local variables, <> for interprocess, and no prefix for process variables. The converter only generates @param tags for $0 through $n parameters. Process and interprocess variable declarations (C_TEXT(vMyVar) or C_TEXT(<>vShared)) are documented as internal variables using an @var tag instead.

The output follows JSDoc 3 conventions: /** */ delimiters, @param {type} name - description format, and @returns {type} description. This format is recognized by most documentation generators including JSDoc, TypeDoc, and Doxygen (with JSDoc filter). It is also parseable by IDEs such as VS Code for inline tooltip documentation.