Hacker News Reader

Comment by pa7x1 | Hacker News Reader

The only situation I can imagine this causing a problem in your codebase is if you intentionally want to mix camelCase and snake_case in your codebase and these 2 meaning different things. So if you don't enforce in your codebase a specific code style practice and you would like someFunction and some_function to coexist and mean different things, then yes. Nim's approach is problematic for you.

If you enforce a code style or, if you don't but you would convene that someFunction and some_function should mean the same thing in your codebase. Then nim's approach should be transparent to you.

View on HN

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'

Use nimgrep?

Can you integrate that into an IDE? In many IDEs, if you hit ctrl-shift-f, it will search the project for the selected text with just one keystroke. Can vscode be made to Do The Right Thing for Nim without extra fiddling on every search?

Good question, but I don't know the answer (yet) because I don't use vscode, sorry.

Your Nim project will be in a consistent casing, otherwise the compiler will be warning you about inconsistent spelling. Regular Ctrl-shift-f will work just fine.

Ripgrep is already integrated into my editor and muscle memory. Nimgrep is just yet another special case tool that only exists because Nim decided to spend its weirdness budget on inconsequential nonsense.

The “weirdness budget” concept is nonsense. Are you saying that programming languages should do only some things right?

@Nullabillity The only nonsense we are dealing with constantly is opinions of people who haven't ever bothered to use this feature before declaring it "inconsequential nonsense".

Why would someone change its tooling because of a particular Language ?

Do you use it regularly? I don't, and I don't have any problem finding what I need with regular ctrl+F in Nim, because Nim projects are internally consistent in terms of style, with the compiler helping enforcing it with `-styleCheck`.

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.

Again, not if you enforce a code style which nearly always should in a professional context.

Such a mistakes is easy for a linter to pick up on so that the code would never be merged in the first place.

How does the linter treat 'get_file_system' and 'get_filesystem'? Which one would be flagged as an error?

The one that doesn't match the declaration.

An earlier comment says:

> 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?

This is a valid observation.

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.

There are warnings raised by default, like this:

test.nim(2, 8) Hint: 'myvar' should be: 'myVar' [var declared in test.nim(1, 7)] [Name]

I think there was a flag that allows you to turn bad style in identifiers into compile errors. It isn't but imho should be on by default.

edit --styleCheck:error perhaps?

Tooling (In this case, "Find References") should understand language semantics. Not that I think that this specific feature of Nim is particularly appealing, but pandering to 1970s stone-age tooling forever is just sad.

You don't always get to pick your tools. If you're using GitHub, ctrl+F should find what you're looking for.

As a C programmer where the codebases I work on have never adopted any sort of style enforcement: sounds like a normal day to me.

It would be one thing (but still a weird feature that calls the rest of their decision making into question) if it normalized fooBar into foo_bar (or the opposite). But that's not what it actually does, it normalizes both into foobar, which introduces new ambiguities. In fact, you can often end up with the opposite meaning! For example, a few Swedish examples:

- hand tvättas (wash your hands) != handtvättas (wash by hand)

- sjuk gymnast (sick gymnast) != sjukgymnast (physical therapist)

- sjuk sköterska (sick nurse) != sjuksköterska (hospital nurse)

- lång hårig (tall and hairy) != långhårig (long-haired)

- sjö nära tomt (lake near a house) != sjönära tomt (house near a lake)

These examples apply to a codebase...how?

Method\variables naming?

I'm a Swede working in Sweden and Norway, and I've never seen any code written in a Scandinavian language (thank god).

Variables are usually named after things, so of course they apply to a codebase. How would they not apply?

Natural language compound words has no bearing on a discussion on Nim. It makes even less sense to use a language full of compound words like Swedish, when Nim is written in English - a language where compound words are less common and flexible.

Nim itself, or the code bases written in Nim?

Nim forces you to use English identifiers?

Another situation is when you have to interface with some other language that doesn't have this feature and where nameLikeThis and name_like_this both exist and mean different things. Thus requiring you to work it around with a third naming convention.

Here's one illustration: https://github.com/nim-lang/RFCs/issues/456#issuecomment-111...

We have partial case-insensitivity in PHP. Can't say I'm very fond of it, but I'm ambivalent as long as it's not abused.

You should rename foreign identifiers anyway. C names are usually very cryptic.

This has a drawback that when reading the original documentation, not only do you have to mentally translate the code examples into your target language, but also translate the identifiers too.

And "C names are usually very cryptic" is plain false, unless you talk about APIs coming from the ages and compilers where all identifiers had to be 8 characters or fewer in length.

> The only situation I can imagine this causing a problem in your codebase is if you intentionally want to mix camelCase and snake_case in your codebase and these 2 meaning different things.

This is literally idiomatic Python style! Classes are TitleCase and everything else is snake_case.

I have also used a mix of camelCase and snake_case for different purposes, eg in Haskell where conventions are mixed (and I am far from an expert), I've written names like "fooBar_prev"

> This is literally idiomatic Python style! Classes are TitleCase and everything else is snake_case.

And Nim does distinguish between those.

> I've written names like "fooBar_prev"

That's disgusting.

I'm not sure I understand the rationale of it if using a consistent naming approach (best practice) renders it transparent, and compiler warnings alert you to instances where one is using e.g. my_var and myVar. Seems like the capability is there but the typical advice and compiler both warn against taking advantage of it. Just seems like a footgun to me. What am I missing?

It's there to allow you to have a consistent naming approach inside your project, regardless of the naming approach of the libraries you are using.

This is done a lot in Python Libraries the module with lower_case and class name with TitleCase . In Nim's Case (No Pun Intended) it is a fatal mistake.

This particular example isn't actually an issue in Nim. The first letter of a nim identifier is case sensitive, so while `my_thing` and `myThing` are normalized to the same name, `my_thing` and `MyThing` are different.

Reply on news.ycombinator.com