2

Referring primarily to here, it suggests that values which are constant in JavaScript (using the keyword const) should be named in SHOUT_CASE. I'm of the opinion though that mutability is much more important (and rare) than immutability, at least in JavaScript, and that having so many variables put in SHOUT_CASE would actually harm readability, rather than aid it, and dilute the meaningfulness of the convention itself.

Now, I understand that SHOUT_CASE for constants is useful in languages that do not have inherent support for constant values built into the runtime - for example, ES5 javascript, where you had var and nothing else. But with language-level support for const values, is there much use for this convention any more?

At runtime, any identifier created using the keyword const cannot be re-used or re-assigned to. This isn't strictly const correctness in the C/C++ sense, but for primitives it is fine. For objects, you'd have to use Object.freeze to get const-correctness. JavaScript is far from the only language to do this, of course. Fields are commonly readonly (C#) or final (Java) [citation needed].

What benefits would having things labelled in SHOUT_CASE present in a language that already has const support built into the syntax?

Improve this question
2
  • 5
    Using SHOUT_CASE was a convention that I learned from C++. This may simply be the perpetuation of that convention, however applicable it is to JavaScript.
    – Paul Rowe
    Jan 12, 2016 at 16:20
  • It depends on the language and the culture surrounding it. In functional languages, all values are by default constant, so naming them all in shout-case would indeed impede readability. For example in Scala one would write val num_files = 5, not val NUM_FILES = 5, because val means the reference can't be changed. Since JavaScript is usually written in an imperative style, non-constant variables are the norm.
    – gardenhead
    Jan 12, 2016 at 20:38

2 Answers 2

Reset to default
7

The main benefit of using SHOUT_CASE for constants is to easily know when reading code when a particular value is not expected to change without having to look for the definition, or worse, having to search for every reference to that variable to see if its value changes.

Improve this answer
4
  • I can understand this, but at the very least I work under the assumption that everything is immutable (for some values of immutable - objects still aren't unless you Object.freeze) unless specified otherwise - i.e, I default to using const instead of let in my code. Is this such a rare thing?
    – Dan
    Jan 12, 2016 at 15:54
  • I personally have not run into many uses of defined constants in Javascript, but YMMV. Most readability guidelines are just that; guidelines. If something makes your code harder to read, then feel free to use a different standard. I often find internal consistency is much more valuable than any single guideline.
    – Gabe Willard
    Jan 12, 2016 at 16:00
  • 3
    @DanPantry: Is this such a rare thing? -- It is. Most Javascript code is not written with "immutability by default" in mind.
    – Robert Harvey
    Jan 12, 2016 at 16:25
  • @RobertHarvey I would argue that a lot of ES2015 is. But I would also argue that that has only been in effect in the past year or so, so it's a poor argument to make.
    – Dan
    Jan 12, 2016 at 16:49
0

Given that SHOUT_CASE is a human convention that can't be dependably parsed, no, it shouldn't be used for languages that already allow defining immutables. It's redundant; everything redundant should be removed mercilessly so that learning the language is as simple as possible for future generations.

In general, programming languages should codify as many human universally useful conventions/classifications/taxonomies as they can. Our program editors/readers should be doing the job of making the program clear for us, as much as possible. For instance, using PascalCase for classes to distinguish instances from their camelCase classes/constructor functions should instead be replaced by editors that render those two distinct kinds of values differently. The next paragraph I write will be visually separated by an empty line. I don't have to write a \n character and you don't have to visually parse it. I don't have to write a bunch of empty " " space characters to visually separate anything. The browser (and 99.9% of other programs that deal with text) is turning that meaningful/semantic information (the newline character) and rendering it in an intuitive, clear, simple way. Markdown will actually turn this paragraph into a <p> tag, which has a specific meaning: "a paragraph of text" - a set of sentences discussing related ideas. Now, Firefox can render this page into a "comfortable reading" mode, and it will include this paragraph, on the assumption that paragraphs represent meaningful content. Screen-readers for the blind can read this text aloud, knowing it's not merely visual UI code. That's how all code editing should work, because code should be marked up with structure and meaning; it's not just text.

Human conventions should be used only where machines can't help us.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.