4 ms·
That means that all three forms will wind up in any Nim project that gets large enough, though. Hardly a good thing.
by FeeTinesAMady 12y ago
That means that all three forms will wind up in any Nim project that gets large enough, though. Hardly a good thing.
- jiggy2011 12y agoIf they all work, does it even make a difference? Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form.
- yoklov 12y agoWell, it's harder to grep, for one (although far from impossible).
- duaneb 12y agoIt has little benefit and requires new tooling to do simple refactoring like "rename". > Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form. This should be part of the language if it's being so lax with identifier uniqueness. And if it's so trivial, you should write it so people can't complain anymore.
- deleted 12y ago[deleted]
- dom96 12y agoI don't get why people get so worked up over this. It's not a "little" benefit in my opinion. In regards to drawbacks I can only see one, and that is grepping for the identifiers becomes more difficult.
- duaneb 12y ago> It's not a "little" benefit in my opinion Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor. Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.
- dom96 12y agoI don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?
- duaneb 12y ago> In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? You don't. It's a terrible idea to mix naming conventions. > amyAtePizza has the same meaning as amy_ate_pizza. WHY?! What possible benefit could it have? Why would you be mixing styles in the first case? Why can't you just remember which style hopefully your entire code base uses?
- dom96 12y agoI wouldn't mix styles inside my own code base. But what if I am using somebody else's library which uses a different style? The benefit is that I can then use the style I have been using in my code base to call the functions in that library without mixing naming conventions.
- Dylan16807 12y agoI hope you never move code between different code bases, then. Wouldn't it be a lot simpler to have a single style?
- scott_s 12y agoI think it will put more cognitive load on the humans who read the code. Instead of doing a quick visual comparison to see if identifiers are the same, programmers will need to actually comprehend the two tokens, and then transform them in their head to see if they are the same. This sounds minor, but I think the cognitive load can add up. Visually comparing two tokens is not quite conscious thought, while comprehension is. It's something you'll always need to think about when reading code.
- rm445 12y agoIt's an unusual feature. Perhaps it calls for a 'go fmt' (nim fmt?) type tool that canonicalises names, to be automatically run on check-in.