russplaysguitar / navel

Working towards a linter for cfscript
MIT License
2 stars 0 forks source link

bracket [] notation #32

Open thinkloop opened 11 years ago

thinkloop commented 11 years ago

Instead of alternating between do-notation and bracket-notation to access static struct keys and variable struct keys, respectively, always use bracket-notation:

YES: myStruct['item1'][var1] NO: myStruct.item1[var1]

Aside from being more consistent, bracket-notation respects the case of your keys, and does not UPPERCASE them. This is very important when, for example, you are serializing your structs to send to backend services, and similar. The only disadvantage is the additional character you have to type (2 brackets instead of 1 period).

atuttle commented 11 years ago

If we add this it should be disabled by default.

adamcameron commented 11 years ago

I agree with... err... Adam. TBH my personal position is to only use bracket notation if there's a need to: when case-preservation is important (generally it's not); or if the key name doesn't obey dot-notation-variable-name rules. "Forcing" it by default just means "more typing" in a lot of situations it's not needed.

russplaysguitar commented 11 years ago

@thinkloop so if the primary reason for this rule is to prevent upper-casing of keys, wouldn't it make sense to only enforce it for variable assignment? simply accessing items via dot-notation wouldn't affect case (although i guess it would be less "consistent")

personally, i dislike array notation (due to the extra typing cost) and only use it when i have to. feedback from "the adams" suggests it might not be a popular default.

maybe we could add a flag via comments that would act as a serialization warning? something like var toSerialize = {}; // lint:brackets? then any assignments to that struct via dot-notation would fail lint.

i think that solution would fall under the "nice to have" category, though, and not be a v 1.0 requirement.

atuttle commented 11 years ago

@russplaysguitar :+1: