lint naming convention - flowr-analysis/flowr GitHub Wiki

This document was generated from 'src/documentation/print-linter-wiki.ts' on 2025-07-23, 11:41:21 UTC presenting an overview of flowR's linter (v2.3.0, using R v4.5.0). Please do not edit this file/wiki page directly.

Naming Convention [overview]

quickfix style

Checks wether the symbols conform to a certain naming convention
This linting rule is implemented in src/linter/rules/naming-convention.ts.

Configuration

Linting rules can be configured by passing a configuration object to the linter query as shown in the example below. The naming-convention rule accepts the following configuration options:

Examples

myVar <- 42
print(myVar)

The linting query can be used to run this rule on the above example:

[ { "type": "linter",   "rules": [ { "name": "naming-convention",     "config": {} } ] } ]

Results (prettified and summarized):

Query: linter (0 ms)
   ╰ Naming Convention (naming-convention):
       ╰ Metadata: {"numMatches":1,"numBreak":0,"searchTimeMs":0,"processTimeMs":0}
All queries together required ≈0 ms (1ms accuracy, total 8 ms)

Show Detailed Results as Json

The analysis required 8.0 ms (including parsing and normalization and the query) within the generation environment.

In general, the JSON contains the Ids of the nodes in question as they are present in the normalized AST or the dataflow graph of flowR. Please consult the Interface wiki page for more information on how to get those.

{
  "linter": {
    "results": {
      "naming-convention": {
        "results": [],
        ".meta": {
          "numMatches": 1,
          "numBreak": 0,
          "searchTimeMs": 0,
          "processTimeMs": 0
        }
      }
    },
    ".meta": {
      "timing": 0
    }
  },
  ".meta": {
    "timing": 0
  }
}

Additional Examples

These examples are synthesized from the test cases in: test/functionality/linter/lint-naming-convention.test.ts

Test Case: simple

Given a symbol definition testVar <- 5 the linter checks if it matches the configured casing rule (here we check for PascalCase) and provides a quick fix TestVar <- 5

Given the following input:

testVar <- 5

And using the following configuration:

{ caseing: CasingConvention.PascalCase }

We expect the linter to report the following:

name:           'testVar',
detectedCasing: CasingConvention.CamelCase,
quickFix:       [{ type: 'replace', replacement: 'TestVar', range: [1, 1, 1, 7], description: 'Rename to match naming convention PascalCase' } as const],
range:          [1, 1, 1, 7],
certainty:      LintingCertainty.Definitely,

See here for the test-case implementation.

Test Case: only detect definition

The casing of the definition is checked, and quick fixes for all usages (and the definition) are provided

Given the following input:

testVar <- 5
print(testVar)

And using the following configuration:

{ caseing: CasingConvention.PascalCase }

We expect the linter to report the following:

name:           'testVar',
detectedCasing: CasingConvention.CamelCase,
quickFix:       [
	{ type: 'replace', replacement: 'TestVar', range: [2, 7, 2, 13,], description: 'Rename to match naming convention PascalCase' } as const,
	{ type: 'replace', replacement: 'TestVar', range: [1, 1, 1, 7],   description: 'Rename to match naming convention PascalCase' } as const
],
range:     [1, 1, 1, 7],
certainty: LintingCertainty.Definitely,

See here for the test-case implementation.

Test Case: function and call

Arguments will be checked for correct casing convention as well

Given the following input:

foo_Bar <- function(arg) arg
foo_Bar()

And using the following configuration:

{ caseing: CasingConvention.PascalCase }

We expect the linter to report the following:

name:           'foo_Bar',
	detectedCasing: CasingConvention.CamelSnakeCase,
	quickFix:       [
	{ type: 'replace', replacement: 'FooBar', range: [2, 1, 2, 7,], description: 'Rename to match naming convention PascalCase' } as const,
	{ type: 'replace', replacement: 'FooBar', range: [1, 1, 1, 7],   description: 'Rename to match naming convention PascalCase' } as const
	],
	range:     [1, 1, 1, 7],
	certainty: LintingCertainty.Definitely,
},
{
	name:           'arg',
	detectedCasing: CasingConvention.CamelCase,
	quickFix:       [
	{ type: 'replace', replacement: 'Arg', range: [1, 26, 1, 28,], description: 'Rename to match naming convention PascalCase' } as const,
	{ type: 'replace', replacement: 'Arg', range: [1, 21, 1, 23],   description: 'Rename to match naming convention PascalCase' } as const
	],
	range:     [1, 21, 1, 23],
	certainty: LintingCertainty.Definitely,
},

See here for the test-case implementation.

Test Case: detect casing

The rule can be configured to automaticaly detect the most used casing style. The file will be linted according to the detected style

Given the following input:

testVar <- 5
testVarTwo <- 5
test_var <- 5

And using the following configuration:

{ caseing: 'auto' }

We expect the linter to report the following:

name:           'test_var',
detectedCasing: CasingConvention.SnakeCase,
quickFix:       [{ type: 'replace', replacement: 'testVar', range: [3,1,3,8], description: 'Rename to match naming convention camelCase' } as const],
range:          [3,1,3,8],
certainty:      LintingCertainty.Definitely,

See here for the test-case implementation.

Test Case: empty string

Given the following input:



And using the following configuration:


{ caseing: CasingConvention.SnakeCase }


We expect the linter to report the following:


* no lints


See here for the test-case implementation.


Test Case: empty string (auto detect)


Given the following input:




And using the following configuration:


{ caseing: 'auto' }


We expect the linter to report the following:


* no lints


See here for the test-case implementation.


              


              

                

                  

                    
Currently maintained by Florian Sihler at Ulm University

Email | GitHub | Penguins | Portfolio


                  

                

              

           
⚠️ **GitHub.com Fallback** ⚠️