5 ms·
This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into a
by nyan4 10y ago
This criticism usually comes from people that do not use Nim.
I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity.
#1: those variables have to be in the same scope or be procs working on the same types to be an issue.
#2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.
- gjm11 10y agoI suspect this criticism usually comes from people who don't use Nim because anyone inclined to be bothered by it will not use Nim for that reason. I agree that "just keep a consistent style" is a good approach for single-person projects. It's harder to keep it working well as you get more people working on the code, though.
- progman 10y agoActually Nim's attitude is more suitable for group work because every group can have its own style of coding. A simple transformer could be used to normalize the code. However it would force the developers to qualify all imported conflicting names which is a good idea anyway. You cannot do this in C++ and Rust. There you actually have to keep a consistent style.