Highlighting Upper Camelized Variables as Constants

[jfelchner]

I'm creating a new issue from #631. This was a point of blockage to getting that PR merged and @amadeus thought it best if we moved it into another issue so that we could discuss it further.

My feelings are that, in most programming languages (and even JS now with ES6 classes and imports) that if you have a variable which is UpperCamelized that it denotes a thing you would like to think of as a constant. Be it a class or a constant variable.

I understand that the syntax stance that you all are taking here is a "semantic" one for the most part. Or: What does the interpreter see this as?

However from my point of view, syntax highlighting isn't for the interpreter, it's for the developer.

While it may be the case that:

import HelloThere from 'hello';

class FooBar extends HelloThere {
  doSomething() {
    // ...
  }
}

the interpreter sees FooBar and doSomething as the same type of object, from the developer's perspective particularly if they're writing class-based syntax, they want to think about those things differently. Otherwise, why wouldn't everything be lower-camelized like standard JS variables?

There has to be a reason why you would choose to go FooBar instead of fooBar and in my experience it's because you want to change the way you think about that variable. Which is what syntax highlighting is for.

So it seems like there's not going to be a consensus on whether to do this or not, but I would suggest a compromise. An option to allow this behavior should the user want it.

if exists('g:javascript_highlight_upper_camel_as_constants')
  syntax match   jsConstant           "\<[A-Z][A-Za-z]\+\>"

  syntax region  jsImportContainer    add=jsConstant
  syntax region  jsDestructuringBlock add=jsConstant
  syntax cluster jsExpression         add=jsConstant
  syntax region  jsDestructuringBlock add=jsConstant

  HiLink jsClassDefinition      Constant
  HiLink jsConstant             Constant
else
  HiLink jsClassDefinition      jsFuncName
endif

The above isn't final but simply an example.

The benefits are that now users can opt-in with a single config variable rather than having to copy and paste this same code everywhere. Additionally, if bugs are found, they can be corrected once and allow everyone to benefit.

The downsides are that it's more code and the conditional causes the syntax to behave differently depending on the settings, which could make debugging slightly more difficult.

[bounceme]

It doesn't seem like a good idea to accomadate peoples js-isms, as they vary. for example, why not make $this, that , ... be highlighted like this ?

[jfelchner]

@bounceme I don't consider this a js-ism. I consider this a fundamental approach to the way that people write code. In most languages.

[bounceme]

So you want every variable that starts with a capital to be thought a class? Sorry but that isn't true for every js dev, much less for anyone not programming in a language with class inheritance, if that matters

[jfelchner]

Of course not.

[jfelchner]

Every variable that starts as a capital should be though of as a class or constant Something that shouldn't be mutated willy nilly.

Please give me an example of a use case where you would use UpperCamel where you weren't talking about:

• A constructor function
• A chain to another constructor/class (eg Foo.Bar)
• A class
• A constant

[jfelchner]

I'm not talking about where you could use it. I'm talking about where you would use it.

[bounceme]

I can think of a few examples where you would need to use a lower case:

console.log(new Number.prototype.constructor())
console.log(new ''.constructor())

all js objects have a constructor property which is lowercase, and can be, and is often, used for inheritance.

[bounceme]

Otherwise I do agree with you. It is just that javascript is a much more flexible language (and people take advantage of that)

[amadeus]

So here's the thing, I don't think any of us disagree that the convention is a good convention or not, or even if it is a very commonly used convention - it is, and it's used in many different languages, etc.

I think the real question is - is it appropriate to create as a feature in our syntax file. I am still not convinced, to me it's a separation of concerns, and this syntax file shouldn't be defining nebulous and potentially inconsistent group names based on a style convention. The project is called vim-javascript, not vim-javascript-style or something related.

[jfelchner]

I look at it like this:

Would most people who develop in JavaScript want to be able to match and highlight items in a jsConstants group (or call it jsUpperCamel or whatever)?

Whether that match group gets linked to Constant can be another discussion, but the group itself is useful to a very, very large number of developers.

By having it in the repo, then bugs can be fixed in one place and everyone benefits. If you're just like "Hey copy and paste this code", then that benefit doesn't happen.

And to be honest, most vim sytnax plugins that I've seen, are opinionated about the common idiomatic style around a given language.

Not saying vim-javascript should be, but it's definitely a common approach.

[jfelchner]

• Ruby: https://github.com/vim-ruby/vim-ruby/blob/master/syntax/ruby.vim#L125
• Elixir: https://github.com/elixir-lang/vim-elixir/blob/master/syntax/elixir.vim#L55-L57
• Clojure: https://github.com/guns/vim-clojure-static/blob/master/syntax/clojure.vim#L73

[bounceme]

js has a few constant number values: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
lots of languages use the UPPER_CASE_UNDERSCORE as a convention for constants, which gives another example of the trouble with preferences and how js is so informal

[bounceme]

If there is other input, let's move the conversation to a p.r.