Variable Names: Wow - That's 'Opinionated'!

[madranet]

The other day, I was tinkering with a small prog in V which involved enabling / disabling some of OSX's LaunchAgents. For my sins, I named one of my variables launchagentenabledpath [OK. It might not be elegant, or what you'd use, but it's how I roll!].

Anyway, to my surprise V refused to compile my prog, because it didn't like the way I'd named the variable:

bad variable name `launchagentenabledpath`
looks like you have a multi-word name without separating them with `_`
for example, use `registration_date` instead of `registrationdate`

Now, I know everyone has their own way of naming variables. Ranging from the folks who like to use cryptic one-letter names like x, to the people [like me] who tend to use VariableNamesThatAreABitMoreDescriptive.

And I know that some programming languages are fussy about what kind of names can begin with uppercase and which with lowercase letters. And then there are languages which require you to distinguish between private and public vars by [for example] beginning the names with an underscore or not. And, at the other end of the spectrum, you have a language like Nim, which is very lax about variable names, being pretty much case agnostic, apart from the initial letter.

But this is the first time I've had a programming language actually refuse to compile unless I changed a variable name –not because I'd used one that was syntactically "wrong" –but just because it didn't like how I worded it.

Is it necessary to be quite so "opinionated" as that?

Interestingly enough, I ran a few long dictionary words through the compiler as variable names [Yes, I do have too much time on my hands!] and found that, rather than any kind of logic for identifying when the miscreant programmer has created a multi-word variable name, it seems the compiler just refuses to accept any variable names longer than 15 letters.

So, ironically iamamultiword [I am a multi word] is acceptable as a variable name, whilst misunderstanding, extraterrestrial and characterisation are rejected by the compiler as being unseparated-multi-word names.

In my case, this was a minor irritation –I want to name my variables how I want [within reason]. But I could see it having a bit more of an impact for people programming in languages like German which tend to be a bit more er... 'longwinded' when it comes to naming conventions.

So, just out of curiosity, why such a relatively short limit on variable names? Did one of the dev team have a traumatic childhood incident involving one of those windowDidNotFinishLoading type names beloved of other platforms and vow never to go there again?

[Toby222]

misunderstanding being a false positive is ironic indeed

[medvednikov]

Update: this error has been removed.

Hi

Good question.

V is indeed very opinionated: it won't allow you to use PascalCase for function and variable names, it will force you to capitalize struct names, etc.

One of the main goals of the language is to have code bases with the same style, so that it's easy to jump into a new code base and feel almost like it was you who wrote it.

I think Go was the first language that was successful at this, V just goes a little bit further.

I wasn't happy about this particular limitation when I introduced it, because it doesn't really look at the words, just at the length. This might be changed to a warning in the future.

[spytheman]

@madranet , I also did not like that restriction at first, but after a while, I now appreciate it. It is a constraint that makes you think about more descriptive and shorter names. In a weird way, such a restriction, makes you more creative in other areas, such as the purpose and goals of your programs, not in the names that you use to express them.

[adlesh]

I think it should remain an error, but could it not just check for the presence of underscores? And require that there's at least an underscore every so many[7 for example] chars? I mean the authpr could still use nonsensical names, but you can't really prevent that any way.

[medvednikov]

I think it should remain an error, but could it not just check for the presence of underscores?

That's what it does right now.

[madranet]

Personally I've always hated the 'underscores-for-spaces' thing. I think it looks really ugly. So, even when naming files and folders on my own comps, I tend to use PascalCase for anything I might want to access via a terminal, so I don't have to mess about backslashing spaces.

Still, I'm not opposed to a language imposing stylistic formatting rules. I just thought it commentworthy that V had adopted such a seemingly arbitrary one.

@spytheman - I also did not like that restriction at first, but after a while, I now appreciate it. It is a constraint that makes you think about more descriptive and shorter names....

I'll try to channel my inner haiku from now on!

@medvednikov - One of the main goals of the language is to have code bases with the same style, so that it's easy to jump into a new code base and feel almost like it was you who wrote it...

Will the compiler be equally as strict with those nasty programmers who insist on giving every variable cryptic one- or two-letter names and demand that they use more descriptive ones?

Now that would be a fun error message:

bad variable name `g`
looks like you have an incomprehensibly short variable name. 
for example, use `old_file_path`  instead of `ofp`

[yarf]

I, also, feel that applying such restrictions in the compiler will become a hindrance; potentially characterizing V as a fringe-language versus mainstream.

I understand there's some intent to interface with iOS libraries? Cocoa et. al. are riddled with long camelCase names such as:

@interface GKGameCenterViewController : UINavigationController 
...
GKGameCenterViewControllerStateLeaderboards

Should V explicitly force iOS programmers to give up that particular naming policy (which exists for good reason) in order to use V?

Same concern goes for the enforcement upon an interface name, which seemingly must end with the string "er".

Programmers are a fairly opinionated group (emacs vs vi? Tabs vs spaces? etc) -- you risk alienating large swathes of those who might benefit from using V, through enforcement of seemingly arbitrary naming conventions ... policy without clear benefit, if you like.

It's one thing to enforce a policy such as "all capitalized names are exported/public, while others are private", as a tradeoff to avoid additional keywords such as 'public' and 'private'. It's quite another to dictate how names are constructed without clear rationality.

I'm just saying there's more to language adoption than one might assume. Ask yourself if you would be happy if the government (etc) were to dictate what you could eat, watch, listen to, or date. How about if they enforced how you could express your artistic side; down to which brushes, colors and textures you were allowed to use. How about which notes on a piano were legal vs not, and in which manner you were allowed to compose a note-sequence? (so-called pop music is pretty much based around four chords only these days; whereas it used to be an artistic endeavor -- that's the A&R constraints showing through).

I will posit that programmers are happy with language constraints where benefits are clear and obvious. V has considerably more potential than Zig and Nim, IMO, largely due to syntactic-simplicity while still offering sufficiently rich functionality. Would be a shame to limit adoption for reasons which really don't offer much tangible value.

All IMO.

Please reconsider, Alexander?

[yarf]

as a brief follow-up I happened to watch this a moment ago, regarding electric versus ICE-powered cars: https://www.youtube.com/watch?v=Hatav_Rdnno

The presenter notes that "people are lazy, so if you want to convince people to buy something then it needs to be more convenient than what they already have".

That resonates with me in the context of this thread, but inverted: it is much harder to convince people to use something if they find it less convenient (for any reason)

[medvednikov]

People are very opinionated, so it's impossible to come up with the style that everyone will like.

Many programmers don't like gofmt: some prefer spaces over tabs, some prefer { on a newline, etc. But gofmt has no settings by design. There's only one style, all code looks the same, and there's no need to spend time on deciding which style to use.

V is the same, just a bit stricter.

[medvednikov]

I understand there's some intent to interface with iOS libraries? Cocoa et. al. are riddled with long camelCase names such as:

These checks aren't used with code that interfaces with other languages.

[yarf]

People are very opinionated, so it's impossible to come up with the style that everyone will like.

Indeed; this is why you risk alienating so many by enforcing your particular style, rather than allow responsible programmers to simply name things in a manner which suits their corporate or team strategy ;)

Many programmers don't like gofmt: some prefer spaces over tabs, some prefer { on a newline, etc. But gofmt has no settings by design. There's only one style, all code looks the same, and there's no need to spend time on deciding which style to use.

Aye, yet here we are discussing naming convention rather than layout. Names have both explicit and implicit meaning whereas layout does not (in V).

V is the same, just a bit stricter.

I suspect we could all agree being strict can be a good thing where benefits are clear, but in this case we are discussing an enforced policy which seems to have no clear rationale?

If there is true strategic value in making all V code seem familiar to those who use the language, then by definition you must surely intend V to have widespread adoption (such that there will be both a large number of V users, plus a large body of code being constructed and maintained). IMO that is more likely to happen where you make some minor concessions to individuality and/or corporate conformity along the way.

My 2c

[spytheman]

@yarf Your beloved team strategy and corporate conformity is not an isolated island. There are other teams, other corporations, that have other preferences, and sooner than later, you will come to use their code.

The number of people 'traumatized' (ok, more like bewildered, but I bet you get my point anyway) by APIs like windowDidNotFinishLoading or RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext is not trivial...

[spytheman]

@yarf about that video: https://www.youtube.com/watch?v=Hatav_Rdnno You are using an argument based on a video from a person, that has vested interest in pushing ICE (he makes videos about engineering ICE and other stuff surrounding the current status quo, while using click bait titles like "How Miserable Is A Tesla Road Trip?" or "The Holy Grail Of Rotary Engines" ...), while defending the status quo about programming languages ;-) ... I find that very curious.

[bokunodev]

@medvednikov sorry to interrupt the conversation. . ~~I understand, if the length of the variable name is limited. but the name itself?~~ I'm happy with the current rules for naming variables.

[spytheman]

The lenght is limited only if you do not put _ in it, @bokunodev . For example, this works without warnings:

fn main(){
  a_very_long_variable_name_that_may_be_probably_too_long_but_that_still_works_and_is_reasonably_readable := 2
  println( a_very_long_variable_name_that_may_be_probably_too_long_but_that_still_works_and_is_reasonably_readable )
}

This however does not work:

fn main(){
  averylongvariable := 2
  println( averylongvariable )
}

V complains about variables longer than 15 characters, that have NO _ in them:

0[12:52:57]delian@nemesis: /v/nv $ ./v run x.v
x.v:2:0: bad variable name `averylongvariable`
looks like you have a multi-word name without separating them with `_`
for example, use `registration_date` instead of `registrationdate`
    1| fn main(){
    2|   averylongvariable := 2
      ^
    3|   println( averylongvariable )
    4| }
1[12:52:59]delian@nemesis: /v/nv $

[spytheman]

So the whole brouhaha is about retarded variables that are hard to read.

[madranet]

@medvednikov - Many programmers don't like gofmt: some prefer spaces over tabs, some prefer { on a newline, etc...

@yarf - Aye, yet here we are discussing naming convention rather than layout.

I think that's the crux of the matter.

I do prefer tabs over spaces, { on a newline, etc. while I'm writing. But that doesn't really matter while I'm coding because I can write how it feels natural to me –-and then run v fmt on it afterwards to make it 'conform to the norm' before I inflict it on a wider public.

However variable naming constraint is something that gets in my way while i'm actually writing the code in the first place. And anything that unnecessarily interrupts that flow is surely not a 'good thing'?

Incidentally. Since previously when I opened this particular can of worms, I've discovered another limitation. I had assumed that, being a modern C21st programming language, V, like all those other new kids on the block would be UTF-8 embracing. However it seems that variable names are also limited to ASCII only:

V

café := "Sid's Greasy Spoon"
println(café)
//
v run chuckme.v
chuckme.v:1:0: invalid character `�`

Comtrast that with:

GO

café := "Sid's Greasy Spoon"
fmt.Println(café)
//
go run chuckme.go
Sid's Greasy Spoon

CRYSTAL

café = "Sid's Greasy Spoon"
puts café
//
crystal run chuckme.cr
Sid's Greasy Spoon

NIM

var café = "Sid's Greasy Spoon"
echo(café)
//
nim c -r chuckme.nim
...
Sid's Greasy Spoon

RUST

let café = "Sid's Greasy Spoon";
println!("{}", café);
//
rustc chuckme.rs
$ ./chuckme
error: café cannot borrow Sid's Greasy Spoon as it belongs to Sid. Actually, it belongs to the bank. But if they keep up the mortgage repayments, it will belong to Sid [and his wife Doris] in 24,3 years time. Please re-enquire about borrowing café then. Meantime would you like a bacon and egg sandwich and a nice cup of tea?

[Just joshing. Rust actually gives: error[E0658]: non-ascii idents are not fully supported]

[spytheman]

@madranet using é and other characters like that, makes your code hard to understand and modify for people that do not have an easy way to type the above sign, nor know French. Using ASCII only for names does not guarantee that the names will be in English, but is a good start...

[spytheman]

Another example: what will you say about variables named ਇੱਕਲੰਮਾਵੇਰੀਏਬਲ or дългапроменлива ?

[spytheman]

p.s. your Rust example was very funny. Are you a professional writer?

[madranet]

@spytheman - Using ASCII only for names does not guarantee that the names will be in English, but is a good start...

Seems like a retrograde step to me. Are we only trying to attract English speaking programmers then?

One of the other languages I mentioned above [I can't remember which one at the mo'] actually makes a selling point of allowing UTF-8 characters in variable names by giving an example in Chinese in the documentation.

Slightly off-topic:

This is one of my personal bugbears. My real world name has an accented letter in it and, even in this so-called enlightened age, I'm forever running up against web forms which ask me for my name and then, when I type it in tell me that it's "invalid" or "not allowed". So I have to complete the form by typing something that's not actually my name but uses the undecorated variant of the letter which is in my name —which, in most European languages, is actually considered a completely separate character. Not just the unaccented letter with a hat on.

@spytheman - what will you say about variables named ਇੱਕਲੰਮਾਵੇਰੀਏਬਲ or дългапроменлива ?

If I was a Sri Lankan [?] or Russian [?] I'd probably be perfectly happy with them. We shouldn't assume that every single piece of code written in a language is intended for a global audience. I don't see anything wrong with people being able to code as much as possible in their own languages –especially if that code is only for local consumption.

@spytheman - p.s. your Rust example was very funny. Are you a professional writer?

Thanks. Not a professional writer. Just an [occasional] amateur word-mangler

[spytheman]

Well, I am a Bulgarian ( дългапроменлива means longvariable in Bulgarian), and I find projects that use native names for program constructs instead of English very jarring, because they cause me to context switch constantly between the language (whose keywords are in English), and the variables. Keeping all in English is much simpler to me.

Also good projects are never for local consumption only. They tend to grow international fast. p.s. I have nothing against user data being in local languages. For it utf8 is great. I object to programming in languages != english.

[medvednikov]

ASCII only names is also a feature. There's no need in complicating the language and the compiler just to make code unreadable internationally.

[madranet]

@spytheman - Well, I am a Bulgarian...

Lucky I put that '?' after 'Russian' then. I was going to assume it was Russian but then recalled that Bulgarian uses Cyrillic too. That must have earned me a few 'Cultural Awareness' points.

@spytheman - I object to programming in languages != english.

I presume you're not a big fan of this project then?

Ironically, as someone who speaks English as a native language [though I'm not English], I tend to leap to the defence of users of other [and minority] languages* —when often [as in your case] the users of such languages don't actually mind being forced to use English.

@medvednikov - I like your pictorial code example. It's actually the first time I've seen emojis being put to intelligent use. Might also be a fun way to get children into coding.

*[I'm from Ireland. For historical reasons we, [along with the Welsh and Scots] tend to instinctively get a bit 'feisty' about any perceived imposition of English —even though we all speak it perfectly well]

[spytheman]

Our capital city - Sofia, got bombed in WW2 by the British, but that said I do not have animosity towards the English people or language... Just the English government(s) at the time.

[spytheman]

I presume you're not a big fan of this project then?

I am not. At all. Such projects will lead to fragmentation and tower of Babel scenarios very quickly. Given the choice, I much prefer to speak and use English, rather than Chinese. I think you will too, if you have the opportunity to live in China for a while - they are much bigger cultural imperialists than the English ever were...

[madranet]

@spytheman - ...that said I do not have animosity towards the English people or language...

Me neither. I live in England and "All of my best friends..." etc. I still bridle a bit though at any perceived enforcement of English coupled with prohibition on the use of other languages. Although I realise this doesn't have anywhere near the same political charge elsewhere, where English is just seen as a convenient lingua franca.

@spytheman - ...I much prefer to speak and use English, rather than Chinese. I think you will too, if you have the opportunity to live in China for a while - they are much bigger cultural imperialists than the English ever were...

Viewed from your part of the world, England's* history probably seems a bit more benign than it does from mine... or places like the Indian sub-continent and parts of Africa. But we're in danger of seeing this interesting and civilised discussion descend into a pointless 'Country X is nastier than Country Y' argument here. So I'll refrain from commenting further on the political side of things.

*[and latterly, substitute 'USA' for 'England' and pretty much anywhere on the globe for 'Indian sub-continent and parts of Africa']

@spytheman - Such projects will lead to fragmentation and tower of Babel scenarios very quickly...

Is that such a bad thing? I'd hate to live in a world were there was only one language used by everyone and one set of cultural norms. What a cultural desert that would be!

"Vive la différence" as they say in a certain other country, which is quite defensive of its own language.

[bfg-coding]

Fascinating conversation but I think at the end of the day, having the language have a standard on how to type it's code will be more useful to the community because everyone will be typing the code in the same style.

With that said I think the conversations should be around what the standard should be. I think this snake_case is a good one because it makes longer variable names easier to read because there is a "space" between the words.

[spytheman]

@madranet I know about the Irish famine and other events, I know about the history of Africa, India and other places too. I also know that Ireland, and all these other places have their culture and language preserved. China has Uyghurs in reeducation camps right now, in 2020.

[spytheman]

Is that such a bad thing? I'd hate to live in a world were there was only one language used by everyone and one set of cultural norms. What a cultural desert that would be!

User data can be in whatever language is needed. I prefer to communicate to my fellow programmers in a language that all understand. For many reasons, this language is right now English.

[spytheman]

Consider how wondrous even this thread is - many people, from many cultures, with different backgrounds, come together and discuss such an important topic as how long variable names should be, and how should they be styled, and in what language should they be written in.

Will that have been possible, if everyone used his own native language?

[cristian-ilies-vasile]

@medvednikov Alex, I would like to suggest to increase the limit from 15 characters to 21.

[bfg-coding]

@cristian-ilies-vasile What would be the point of increasing the characters?

[cristian-ilies-vasile]

@JustinR93 Well, if the threshold is higher more people should be happy. It's a political workaround.

[Puzomor]

If the goal is to enforce separating words with underscores, then it's obvious a fixed character limit will not successfully accomplish this task. If the language already limits the character set to ASCII then it's reasonable to assume that only identifier names in English are accepted.

In that case, compiler just needs to have a spell checker that's modified so that underscores are treated as spaces. Maybe also include a dictionary file with the compiler toolset, such as https://github.com/dwyl/english-words/ ?

[markonius]

@Puzomor Have you seen the comment by @medvednikov?

ASCII only names is also a feature. There's no need in complicating the language and the compiler just to make code unreadable internationally.

The spell checker would be too complex for the benefit.

[Puzomor]

@markonius I disagree. Obviously v aims for strictness and correctness and I think the benefit with having the spell checker is huge in those departments. As @medvednikov said, making the code as readable as possible is a valid goal, and having misspelled or straight up non-words heavily undermines this goal.

Readability matters, but how can we be expected to read words that don't exist? Enforcing only proper words from a common dictionary will make sure every codebase is equally readable.

[madranet]

having misspelled or straight up non-words heavily undermines this goal.

I think this is going w-a-a-y too far!

Even accepting the fact that the language should impose English on the coder [which, as per my above comments, I already think is unnecessarily restrictive], how would this theoretical dictionary of acceptable words be maintained?

The English language is changing and evolving all the time, with new words being added and old ones falling into disuse. What about words like 'retweet', 'flickr', 'facebook', 'selfie', 'bluetooth', 'wifi', 'bitcoin'... etc? Twenty or so years ago, none of those words even existed.

So, what happens when next year [and the year after and the year after that...] new words come into everyday use in the language? Is someone supposed to maintain a 'current usage' English dictionary for the compiler's benefit? I'm sure the V project will have far more pressing matters to attend to than wasting programmer hours on that.

And, as regards 'misspellings` –where does that end?

For us folks on the right side of the pond, words like 'color', 'center', 'fiber' [thanks Crystal!], '\<anything>-ize' are already misspellings that we have to grit our teeth and put up with when accessing most languages' stdlibs and modules. Are we now to have the compiler refuse to co-operate because we named one of our variables 'colour' or 'digitise'?

[And, in an own-petard-hoisting manoeuvre, some people might even contend that your `misspelled' is a misspelling of 'mis-spelled'! ]

[Puzomor]

I understand your concerns but I think having a dictionary will be less faulty compared to hard 15-character limit. We already established that v is English-only language and that readability is important.

Maybe settling for a single variation of English language is not a bad thing. In no code base will a programmer ever have to worry whether to type "colour" or "color" in a string. I only see this as a win compared to absurd false negatives and false positives a fixed character limit has, as you pointed out.

I think it's absolutely clear what fixed-character-limit is trying to achieve, why it's completely failing to accomplish it and how we can better achieve it.

[madranet]

Maybe settling for a single variation of English language is not a bad thing.

OK. So long as it's proper English then and not that mangled monstrosity the Yanks have come up with.

[bokunodev]

@Puzomor prevent misspelled words etc. it must be the responsibility of the programmer and not the compiler.

[medvednikov]

Using a spell checker is going too far I think :)

[spytheman]

I like the idea of a spellchecker, just not as part of the compiler, but in a linter like tool (so it would not slow down the actual compilation nor increase the size of the compiler much), and you could run it in a separate step, say before commiting.

[medvednikov]

Using a spell checker in v vet actually sounds good.

[bombsimon]

I think it's a good idea to enforce min and/or max variable length and also enforcing a naming standard like snake case.

Pylint forbids single character variable names and even though a quick Google search shows that it's a divisive question I don't really feel that developers have a hard time adapting Pylint or PEP8. I think it's good for a language to have authors with a clear definition of coding style and coding conventions. This just removes a lot of discussions and arguments regarding style.

It's obviously harder to forbid long names compared to short names but this could be handled in several ways.

• Just use another variable (misunderstanding -> failure_to_understand)
• Raise the threshold from 15 characters (configurable upper bound?)
• Comment directive like this:

  misunderstandings := 0 // please compiler: i-promise-its-a-word
  if misunderstandings < 1 {
  println('there were no misunderstandings in this code!')
  }

The last suggestion would also learn people to be nice by saying please!

[Puzomor]

@bombsimon

Using a different variable name could be difficult. It's not always easy to think of appropriate synonyms, and it doesn't always make sense to use a description of a word in place of that word. That's just unnecessary burden on the developer.

It's definitely not comparable to single-character variables. Even more, it's exactly the opposite problem.

Let's say a developer didn't want to use a generic variable name like b and opted into using a more descriptive and yet concise name, like misunderstanding. What do you think the developer will do when presented with an error message that says you can't use more than 15 characters? Try to think of a synonym or look into a dictionary, or maybe they will decide NOT to break their flow and just name the variable b?

Raising the threshold also raises the amount of false negatives. There will be even MORE cases where the developer can put multiple words in an identifier without separating them with underscores - just like iamamultiword.

Using comments to silence the compile errors is a huge anti-pattern. Having to type useless comments to silence the possibly important warnings makes me cringe every time. It also completely defeats the purpose of warnings.

It's time to reflect what the limit is trying to achieve. The limit is trying to prevent developers from combining multiple words without using underscores. The questions I'd like to raise are:

• Does this happen often enough and is it a problem big enough to justify making the programming harder on the developers who name their variables correctly? (misunderstanding)
• Does the 15-character (or any N-character) limit prevent a considerable amount of bad code style? (iamamultiword)
• Do better alternatives exist?

In my opinion, the answers are no, no, yes*. The * on the last answer is my proposition for the spell-checker, which has immensely lower number of both false positives and false negatives, but I'd still argue that it's only reasonable to use it only in either -prod builds, or in some kind of linter.

[bombsimon]

I understand you and I agree with most of it, thanks for your detailed insight. The compiler comment was lacking the /s, it was a joke.

I think this would be something that might yield error with v vet and let the end user desire wether or not to take action. Maybe it could be managed with severity levels (think perlcritic). If this were to be moved to a linter/vet I think all checks regarding variables should live there and none in the language's parser.

I still think that a strict code style and preferred way to write code like effective Go is good. If I ever end up in a discussion about naming variables in v I want to be able to rely on documentation from the authors/community regarding min/max length, casing, max line length etcetera.

To be fair though, I think the biggest problem with bad variable naming is abbreviations no one understands and that's probably more or less impossible to do something about (unless it's just one character).

[darkoverlordofdata]

Well, I now finally understand this error:

bad variable name `internationalization`
looks like you have a multi-word name without separating them with `_`
for example, use `registration_date` instead of `registrationdate` 

That error message makes no sense, because internationalization is definitely not a multi-word name.

I've been pulling my hair out on this one. I just wish this had been documented somewhere so I would have understood why I was having this problem.

I suppose I could use 'i18n' instead. But the thing is, there are words longer that 15 chars, and if I always have to abbreviate them, I would be inconsistent unless I abbreviate everything. And abreviation in general is a terrible coding practice.

It's your language, you set the rules, but really? This has got to be the weirdest arbitrary rule in a language I've ever run into. I'm still trying to decide if I want to use V, and this certainly isn't helping. I'm starting to think it has too many odd features to take it seriously.

[medvednikov]

I've removed this error entirely.

[medvednikov]

Indeed it makes no sense to use the length limit, since it doesn't catch names like numberofids but gives a false positive for names like internationalization.

As suggested, a proper spell checker may be added to v vet in the future.