7 ms·
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
by pa7x1 4y ago
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.
- overthrow 4y agoIt 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'
- michaelsbradley 4y agoUse nimgrep?
- overthrow 4y agoCan 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?
- michaelsbradley 4y agoGood question, but I don't know the answer (yet) because I don't use vscode, sorry.
- Manabu-eo 4y agoYour 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.
- Nullabillity 4y agoRipgrep 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.
- xigoi 4y agoThe “weirdness budget” concept is nonsense. Are you saying that programming languages should do only some things right?
- planetis 4y ago@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".
- Nullabillity 4y ago[flagged]
- planetis 4y agoVery mature, congratulations! Naming has nothing to do with style insensitivity. You can write M_ya_wse_s_omEv_ar in any language, yes? Proof that you don't understand what you're arguing about.
- Nullabillity 4y ago> You can write M_ya_wse_s_omEv_ar in any language, yes? Yes? That doesn't mean that we should add features that encourage that kind of confusion. Especially not when they, again, help nobody and bring no actual benefit.
- monetus 4y ago(Not who you responed to) Just to argue against there being no benefit, I have a cognitive impairment that occasionally puts me in an altered state, a delirium to varying degrees. camelCase is much more difficult to read at that point, so I can get confused ridiculously easily. I tend leave a bunch of comments and then step away, but sometimes I can work well through it; things like horrendous variable names/regexs will throw me. I default to snake_case but compile over when I share the code. This is my unique situation and predilection to being able to read one form more easily than another, but it does indeed help me.
- Nullabillity 4y agoThat's understandable, but doesn't that cause the same issues when reading documentation or third-party code?
- v3ss0n 4y agoWhy would someone change its tooling because of a particular Language ?
- Manabu-eo 4y agoDo 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.
- cardanome 4y agoAgain, 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.
- overthrow 4y agoHow does the linter treat 'get_file_system' and 'get_filesystem'? Which one would be flagged as an error?
- deleted 4y ago[deleted]
- ptramo 4y agoThe one that doesn't match the declaration.
- overthrow 4y agoAn 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?
- pa7x1 4y agoThis 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.
- planetis 4y agoThere are warnings raised by default, like this: test.nim(2, 8) Hint: 'myvar' should be: 'myVar' [var declared in test.nim(1, 7)] [Name]
- darthrupert 4y agoI 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?
- frou_dh 4y agoTooling (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.
- mtinkerhess 4y agoYou don't always get to pick your tools. If you're using GitHub, ctrl+F should find what you're looking for.
- xxpor 4y agoAs a C programmer where the codebases I work on have never adopted any sort of style enforcement: sounds like a normal day to me.
- Nullabillity 4y agoIt 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)
- netbioserror 4y agoThese examples apply to a codebase...how?
- konart 4y agoMethod\variables naming?
- fredrikholm 4y agoI'm a Swede working in Sweden and Norway, and I've never seen any code written in a Scandinavian language (thank god).
- dieortin 4y agoVariables are usually named after things, so of course they apply to a codebase. How would they not apply?
- tokai 4y agoNatural 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.
- 4y ago
- WesolyKubeczek 4y agoAnother 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-1113989084 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.
- xigoi 4y agoYou should rename foreign identifiers anyway. C names are usually very cryptic.
- WesolyKubeczek 4y agoThis 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.
- nerdponx 4y ago> 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"
- xigoi 4y ago> 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.
- v3ss0n 4y agoThis 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.
- dsrw 4y agoThis 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.
- 000ooo000 4y agoI'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?
- Manabu-eo 4y agoIt'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.