Rule to require leading underscores in private variables
See original GitHub issueHi! In OpenZeppelin we use leading underscores for private
variables and functions, and internal
functions (to both emphasize this attribute, and avoid clashing with public
names).
Would it be possible to add a rule to enforce this sort of thing? I currently need to disable some rules, since e.g. I have private
variables that are also constant
(bytes4 private constant _INTERFACE_ID_ERC165 = 0x01ffc9a7
), and the snake case rule doesn’t support leading underscores.
Thanks!
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
c# - To underscore or to not to underscore, that is the question
In our team, we always use an underscore prefix for private fields. Thus when reading some code, I can very easily identify private...
Read more >variable-name - Rule
"allow-leading-underscore" allows underscores at the beginning (only has an effect if “check-format” specified); "allow-pascal-case" allows PascalCase in ...
Read more >What are the arguments for and against naming private ...
In Java I am a strong proponent of naming all *instance* variables (and not necessarily only private ones) this way. Maybe the convention...
Read more >Configure Visual Studio to Name Private Fields with Underscore
Configure Visual Studio to Name Private Fields with Underscore · Click on Tools in the menu. · Click on Options. · Click on...
Read more >When to prefix a variable with underscore? - MSDN - Microsoft
So if I used lower letter for private property variables in my constructor i need to have this code: this.x = x; this.y...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Oh, you fixed that: e3aa88f 😅
Those test cases look good! There’s only one you might want to change:
I think the default is
private
, so this should be fine (we always make the visibility explicit though).Thanks for taking a look at the dev3.0 branch! From a quick overview those warnings seem to be correct - that’s why we want a linter 😂