Hacker News Reader

Comment by gjm11 | Hacker News Reader

That seems like a really bad idea. It means that searching for an identifier requires you to allow for the possibility that there might be any number of underscores inserted anywhere. I suppose in practice you'll rely on the fact that no one will be inserting them other than at word boundaries, but it still seems horrible.

(I'd worry about ambiguities of the experts exchange / expert sex change type, too, but my guess is that they're extremely rare and usually either harmless or instantly caught by the compiler. Still, the mere possibility makes me twitchy.)

View on HN

I would consider it bad style to abuse the case-insensitivity like that.

It can be used for good too, for example if you have a bunch of different naming conventions in the libraries you use:

  proc some_lib_function(x: int)  = echo "hi ", x
  proc anotherLibFunction(x: int) = echo "hi ", x
  proc crAzY_LIB_WRITERS(x: int)  = echo "hi ", x

Then you can still call them consistently:

  someLibFunction(10)
  anotherLibFunction(11)
  crazyLibWriters(12)

The reason of this (while I agree with you) is because Nim comes with a strong interop with C/C++ so the problem is that in C and C++ there is a SnakeCase debate still open. They did that so your program can invoke c (or even nim libs) without taking care of the upcase/underscore style and use your own.

While this seems problematic they added some neat features to avoid problems with `uniqueness` of the name and so on.

One thing I wish at this point is to force the compiler to stop if this pattern is not uniform within a codebase.

Maybe you're thinking in terms of a text editor and not an IDE? With an IDE, you look for symbol references, not text with regexps. You could imagine that the IDE's search would be smart enough to know that if you look for foo_bar, it should also report occurrences of fooBar.

Either way, I still find the idea a bit weird. If the language wants to be opinionated about naming, maybe it could simply make _ illegal in an identifier or, to push it one level further, refuse to compile any identifier that is not camelCase.

I was thinking of both. An IDE is worse unless it's actually targetted specifically at Nim, because its code for finding symbol references surely won't know about Nim's underscore-blindness.

(But I'm not much of an IDE-user myself. Perhaps modern IDEs have enough hooks that you really can control this stuff?)

I'm personally not too happy about this, but there are restrictions on the use of underscores:

- You cannot have two underscores in a row

- You cannot have a leading underscore

Certainly, I would have some sort of lint to enforce naming conventions. I don't like it at all. Searching for a function becomes a nightmare.

The Nim compiler offers a set of tools intended for use in IDEs ant text-editors that help with this. Besides the style insensitive grep, there are also a compiler-assisted "go to definition" and "list references" commands.

Is it not good enough to have specific grep tools? nimgrep for example, and there are procs for working with this IIRC.

I prefer to have a consistent code base, then I can use the internal tools of my editor, which are not aware of Nim's identifier rules.

Reply on news.ycombinator.com