How to check if variable name conforms to specification about nsiqcppstyle

[kunaltyagi]

AFAIK, this is not possible since it is near impossible to differentiate between function call, variable and class/struct names in following syntax:

• x = alpha(3.5); Is alpha a variable, function or class?

It might be possible to create a specific lexer path for identifying variable declarations, but that would imply lots of code changes and implementation of backtracking: not a simple undertaking

[Eureca2017]

If you can check the variable naming convention in the case of variable declaration, it will also help developers write code. So can we consider adding this rule in the future？

[mosherubin]

This is one of the cases where an AST ("Abstract Syntax Tree") linter like Clang-Tidy is superior to a heuristic linter like NsiqCppStyle. Don't get me wrong: NsiqCppStyle is simpler to program for in, say, 80% of the cases.

Having said that, my first thought was what @kunaltyagi wrote: writing a rule to "attack" the variable at its definition/declaration point, checking its naming conformity, and outputting a warning message if it does not. This is much simpler than the well-nigh impossible task of NsiqCppStyle's identifying a variable within complex code. Correcting the variable at the definition/declaration point will produce compilation errors when rebuilt ("'camelBackVariable is undefined").

@kunaltyagi intimated that making this change in the engine is doable but will take time. The poster can, of course, write his own rule that is capable of identifying a variable definition/declaration, but then others cannot benefit from this generic and valuable rule code.

I'd like to suggest a medium-range enhancement to NsiqCppStyle: the ability for users to share NsiqCppStyle code:

• Share full-fledged NsiqCppStyle rules like the one just mentioned.
• Enable a private user-written rule to import valuable shared Python code snippets and functions (e.g., identifying camelCase, PascalCase, snake_case)

The snippets are not part of the NsiqCppStyle engine; rather, it is shared code uploaded by NsiqCppStyle rule writers who believe they have generic code of interest to other rule writers. The snippet should conform to repo coding standards (e.g., it should have built-in unit test cases, it should include internal documentation describing how to use it). It is entirely up to a rule writer whether he wishes to import the snippet into his own rule.

The power of this scheme is the ability to provide a stop-gap measure to improve the NsiqCppStyle engine without tinkering with its internals. As time progresses, especially valuable snippets can be implemented within the NsiqCppStyle engine.

So, to @Eureca2017, you might want to write your own rule code to identify variable definitions/declarations, checking naming conformity at that point, and even sharing it here. If the coding snippet library idea is implemented, that code will be a prime candidate for inclusion.