It also makes it harder to grep. If you're on a team of 10 devs someone could have accidentally forgotten an underscore sometime last year. So you can't just grep for 'ready_for_upload', you have to use 'ready_?for_?upload'
I suspect, in practice, almost everyone follows the sane approach of enforcing a code style in your codebase. I think what usually gets lost when this is brought up is that the point of this code style insensitivity is not to encourage you go to crazy and mix and match it in your projects. It's so external dependencies don't have to infect your codebase. So you can actually apply a consistent code style within your project.
test.nim(2, 8) Hint: 'myvar' should be: 'myVar' [var declared in test.nim(1, 7)] [Name]
edit --styleCheck:error perhaps?
Such a mistakes is easy for a linter to pick up on so that the code would never be merged in the first place.
> It's so external dependencies don't have to infect your codebase. So you can actually apply a consistent code style within your project.
Say an external dependency has a declaration called 'getFileSystem', and in my Nim codebase I refer to it as 'get_file_system', but last year someone accidentally committed 'get_filesystem'. In this case neither usage matches the declaration. Does the linter flag both spellings because they don't match 'getFileSystem'?
EDIT: And what about reflection? If someone wrote `newCall("get_filesystem")`, will the linter fix that too?
So don't bring up nimgrep like it's a necessity when it's more of a last resort tool nowadays. You will be just attracting flaming.