Monday, November 06, 2006

CFC Fight Club Rules

A bit of a rant, but lets have some fun with it. I have lots of candidates for numbers 7 and 8. Any thoughts on what they should be? Preferably framework agnostic.

  1. 1st Rule: You do not reference external scopes in a component.


  3. 3rd Rule: Always use "var" for private variables in your methods including loop counters and query names

  4. 4th Rule: Always explicitly scope references to the arguments scope.

  5. 5th Rule: Always create an "init()" method to get your component started. Avoid the use of the implicit constructor since it can't take arguments.

  6. 6th Rule: Avoid using the "this" scope unless it is for something you KNOW is never going to change. Otherwise, code that uses your cfc will be susceptible to errors caused by changes in your cfc code.

  7. 7th Rule:

  8. 8th Rule:


  1. Replace "persisent" with "external" (form/url/request aren't persistent but still shouldn't be directly accessed from a CFC)

    7) Favor composition over inheritance

    8) Avoid the uber-CFC

  2. Right on. Made the change for external vs. persistent. Regarding your #7, I'm still looking for an elegant way to include a reference to a "helper" component that does things like dump() the values of the private properties and handle some generic setup. I currently have that sort of thing floating around in a "base" component that others extend, but that seems to violate the extension concept of "is a" unless you think in very generic terms like: myComponent is a(n) object.

  3. helper/utility classes should either be injected or individually created. I favor injection because I've had utility classes that at one point had some simple UDFs but eventually expanded to having to read properties during startup, consult other APIs, etc. Having only one instance floating around can be very nice!

  4. 8th Rule: When the situation is appropriate ignore rules 1 - 7. No rule is perfect in every situation.

  5. Hey Gus, normally, I'd agree with you, but I don't think that should make it onto the rules. As soon as you do that, then it seems like everybody's situation requires some exception. If you're going to break a rule, you should feel like you're breaking a rule and accept the consequences. The real problem comes when somebody has to come behind the rule breaker and clean up their s**t.

  6. What about a rule about always scoping internal CFC method calls. This might seem silly, but I find it can get confusing (and can cause naming conflicts). For example let's say a CFC has a method names Sort(). If I see Sort() somewhere in the code (inside the CFC), then I have to stop and think if its a CFC method or a built in ColdFusion method (come on, it sounds built it). But, if I see THIS.Sort(), then red flags go off about it being a CFC-scoped method.

    Any takers on this one?