acrmp/foodcritic — pull request #97 by sethvargo (2012-12-28 01:58:12+00:00)
Title: Re-Add FC001 with dedicated tag

I'm not happy that FC001 is gone, and here's why. (Original PR to remove: #86)

Just because people *prefer* symbols doesn't mean they are the best choice.

Functionally there is no difference, but pedagogically there is, thus I argue this is **not** a bike shed. Symbols introduce multiple edge cases, specifically interpolation, performance issues, and standardization.

Interpolation
------------------
You can't interpolate with symbols. So if you're dynamically combining a node attribute, you have to jump between symbols and strings - why not just use strings in the first place? This is incredibly confusing to a new Cheffer. "Use symbols, unless you need to interpolate or use a variable, then use strings". Why does that even make sense?

You're **going** to have to use strings at some point, so why not use them all the time.

Performance Issues
-----------------------------
Under the hood, Chef converts everything to a mash, so it really doesn't matter how you define your attributes... unless you're running ree that is. On ree, converting a symbol of > length 32 **leaks** memory. This is a known and documented issue. So, for older organizations running ree, adopting Chef in their infrastructure may prove to be a HUGE memory hog because of the underlying mash conversion.

This is admittedly a stupid argument, but worth noting.

Standardization
-----------------------
This is the bulk of my argument. I really don't care how we lookup attributes, but we should use **one**. Do you know how confusing it is to a new Cheffer to grasp the idea that `[:attribute]`, `['attribute']`, and `.attribute` are all the same thing? The community cookbooks are littered with a wide variety. Pick a standard and stick to it. Strings are the only logical standard.

There's no reason that Chef should support 100 different ways to write/lookup attributes. From a pedagogical standpoint, it's an absolute nightmare.

Other Stuff
----------------
1. From a maintenance standpoint, it makes finding attributes difficult in a large project. Do I search for `[:attribute]`, `['attribute']`, or `.attribute`. If I'm contributing to a community cookbook, I have to determine if the maintainer "chose" symbols, strings, or methods.

2. If I'm search across a project for an attribute, I have to use a regex or do 3 searches. That's dumb.

3. Both environments and roles use **strings** for the attributes. If you're using JSON (as you should be) for those, you **have** to use strings.

4. I don't think the small sample at Summit is enough to remove this rule - they are intermediate-expert Chef users.

Solution
------------
@acrmp I propose adding this rule back with it's own, dedicated tag (`FC001`) which people can choose to ignore.

To summarize, this was and still is a great rule that should not be removed. It reduces the complexity and ambiguity of attributes which helps with standardization. Please add it back.