> -> IntelliSense / Code completion If it is really so "intelli", it should follow your casing (and guess your casing from the file you are editing).
I don't use code completion so I may not be the right person to discuss this. > -> People following guides. Good luck on that. I can guarantee that unless > you work for a dictatorship team, different styles will flow out. Its extreme > hard to change people there previous build up experience / training. Maybe. I do follow guides and change my casing styles for different non-personal projects. You have to follow the Linus Torvalds style in order to participate in the Linux kernel development, right? (Maybe he is too dictatorial as an example here.) > -> External developers. Good luck again on getting them to perfectly follow > the casing guide. In general they work on different projects for different > departments or clients. So different styles will show up. Or simply laziness > with code completion. Its nice in theory, in practice things always turn out > different. But at least a single style per file should be enforced. * * * > identifier_comparison_ignore_underscore > identifier_comparison_ignore_case_first_letter > identifier_comparison_ignore_case_rest_letters Sounds perfect to me. It will > add a large amount of flexibility. And if that integrates with code > completion, there is no reason why styles differ ( if the IDE's ). And if > people are bothered with the "free" casing style, it can now be reported that > you can have free or fixed styling. More options, more fun cjxgm: Want to put > it forward to the Nim committee for a vote? It's just an initial thought. But it still can't solve the problem: It encourages the design of GL_INT/GLint, and a library with that design can't be used by your partial casing code, and you still need a wrapper that is case-sensitive to reexport them as cGL_INT/GLint.
