Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

naming-convention

Flags identifiers that don’t follow Garmin’s Monkey C coding conventions.

Rules

CategoryPatternExample
Modules & ClassesPascalCaseMyClass
Functions & parameterscamelCasemyFunction(myArg)
Public class memberscamelCasevar myValue;
Private/protected/hidden class members_camelCaseprivate var _value;
Module-scope variablescamelCasevar myCounter = 0;
Local variablescamelCasevar myTotal = 0;
Enum variantsSCREAMING_SNAKE_CASE sharing a <PREFIX>_COLOR_RED, COLOR_BLUE

Rationale

Naming conventions buy consistency at zero ongoing cost — readers don’t have to wonder whether myThing is a class or a function. The rules above mirror Garmin’s official conventions verbatim.

const declarations are left unchecked, not as a gap but because Garmin’s conventions don’t define a case for them — there’s nothing to enforce. SDK code commonly uses SCREAMING_SNAKE_CASE for constants (an idiom like example.SOME_CONST reads better than example.someConst), but that’s convention-by-example rather than a documented rule, so the linter leaves both module-scope and class-scope const alone regardless of visibility.

Example

Before:

class example {
    var Value = 1;

    private var mCounter as Number = 0;

    function MyFn() {}
}

enum {
    RED,
    BLUE,
}

The rule flags each violation and suggests a conformant name via convert_case:

class `example` should be PascalCase, e.g. `Example`
public class member `Value` should be camelCase, e.g. `value`
private class member `mCounter` should be `_camelCase`, e.g. `_mCounter`
function `MyFn` should be camelCase, e.g. `myFn`
enum variants should share a common `<PREFIX>_` prefix

There is no auto-fix — renaming an identifier has to ripple through every call site, which the linter can’t do safely with byte-level replacements alone.