3

How would we or should we carry over Java or other C-like casing conventions for constants to JavaScript?

In Java we would name a "constant" (static final) member with ALL_UPPERCASE. If we had a set of values we wanted as constants, we could use an enum member, and we'd name the enum member with a HumpBack name, but the seperate enum's would be UPPERCASE, e.g. SomeClass.SomeEnum.SOME_VALUE.

So lets say I have a JavaScript library used for some Star Trek game (picking a silly example), with a root namespace object StarTrek. I've got some constant values (never mind that Js has no constants) I want to build in for alien species, attributes of planets. Without thinking about the Java conventions, I'd have went for something like:

StarTrek.SPECIES = {
    HUMAN: "HUMAN",
    KLINGON: "KLINGON",
    VULCAN: "VULCAN"
};

StarTrek.PLANET_ATTRIBUTE = {
    CLASS: {
        M: "M",
        T: "T",
        ...
    },
    LIFE_FORMS: {
        NONE: "NONE",
        INTELLIGENT: "INTELLIGENT",
        NO_INTELLIGENT: "NO_INTELLIGENT"
    }
};

Note that unlike Java, we have something that is like a nested "enum" here in the PLANET_ATTRIBUTES. I've went for uppercase "enum" names here because it feels like everything below StarTrek. is essentially supposed to be "constant" (vs in Java where the enum is actually a Class, hence the BumpyCase name). So anyway I could specify that there where no intelligent lifeforms by using StarTrek.PLANET_ATTRIBUTE.LIFE_FORMS.NO_INTELLIGENT.

Now, following Java's conventions I would have gone with something like:

StarTrek.Species = {
    HUMAN: "HUMAN",
    KLINGON: "KLINGON",
    VULCAN: "VULCAN"
};

StarTrek.PlanetAttribute = {
    Class: {
        M: "M",
        T: "T",
        ...
    },
    LifeForms: {
        NONE: "NONE",
        INTELLIGENT: "INTELLIGENT",
        UNINTELLIGENT: "UNINTELLIGENT"
    }
};

In which case I would specify that there where no intelligent lifeforms by using StarTrek.PlanetAttribute.LifeForms.NO_INTELLIGENT.

Which fits JavaScript better and why? Are there any conventions proposed for this?

Community
  • 1
  • 1
jwl
  • 10,268
  • 14
  • 53
  • 91

1 Answers1

0

The answer is: it really doesn't matter (at all)!

The second convention looks better (first one shouts at you) and is used in C# too, but it depends on you! I think there is no restrictions about this.

But about enums values in javascript: maybe this would be better? You can use your enums as flags.

StarTrek.Species = {
    HUMAN: 1,
    KLINGON: 2,
    VULCAN: 4
}

Edit:

As Jason said, in javascript there is not any concept of constants, so it depends on your choice.

Community
  • 1
  • 1
Are
  • 2,160
  • 1
  • 21
  • 31
  • To add to this. Keep in mind that in JavaScript there really is no such thing as the concept of constants. Species in this scenario is just an object and it's values can be changed. – xspydr Jan 23 '14 at 18:29
  • I've found the key=value pattern to sometimes work better here, makes validation easier. E.g. the user passes in StarTrek.Species.HUMAN to my function, but I just get a String; I can check by seeing if it exists in StarTrek.Species. `function setSpecies(species) { if(!StarTrek.Species[species]) { throw new Error('Unknown species'); }; this.species = species; }` – jwl Jan 23 '14 at 18:30
  • I acknowledged the lack of Js real constants in my question "never mind that Js has no constants". However, while it cannot be enforced it is still a good concept and naming convention. – jwl Jan 23 '14 at 18:32
  • @jlarson Yes. I just mentioned the c-sharpy enumerates. – Are Jan 23 '14 at 18:33