Home > Articles >

Bad Habits, Good Habits

We all do things a bit different and that's just swell. Some things we do just because that's how we do it. Maybe we learned something by example and never applied our own technique to it. Maybe we figured it out on our own, but never refined the process. Regardless why we code the way we do, here are a few things I have STOPPED doing, and a few things I have finally STARTED doing - or - Good Habits, Bad Habits.

Good:
Descriptive variable naming. Let's use a set of phone numbers as an example. If we named the variable holding the phone numbers 'numbers' will you be able to tell what that variable is in 6 months when you make an update? A better example might be 'phoneNumbers' or 'employeePhoneNumbers' or something else that tell you immediatly what that variable is. But that's not the end of it either...

Good:
Use variable prefixes to identify the type of variable. If you have a variable named 'numbers' can you tell me what that is, and how to deal with it. Is it a list? A structure? An array? query? I dunno... Try prefixing your variables with the data type to easily figure out whats happening. A list of phone numbers might become 'lsPhoneNumbers'. Was it an array? Try 'arrPhoneNumbers'. Structures might be represented as 'strPhoneNumbers'

I generally use the following prefixes:
ls : List
arr : Array
str : Structure
q : Query Object
b : Boolean
obj : Object (cfc, com, etc)

String and Integer I haven't got into the habit of prefixing - but probably should.

Bad:
Extraneous pound signs (hash,number sign, whatever). There are times when there is simply no reason or need to use the # in your code even when a variable should be evaluated by CFML. For instance, the most common situation might be . The # is only needed when CFML should evaluate the variable inside of a regular string of text such as This is my text string: #sThisVar#. It is also generally acceptable to use # while evaluating a variable in a tag attribute: . My biggest gripe with extraneous #'s is that it is much harder to read the code, and it is simply extra work that is not required and has no benefit.

Bad:
Using the evaluate() function! There is virtually no reason to use it in most peoples code, yet I still see if quite often. While CFMX and newer might not have the performance issues that CFML 5 might have had, there is still no justification for using evaluate() in most cases. Now some might say, 'But what about dynamically named form fields?' To that I say, 'What about them?'

Assuming the form page created the field names 'form.myField1' through 'form.myField10' by looping from 1 to 10:







What many people forget is that FORM, URL, VARIABLES and virtually all the variable scopes in ColdFusion ar really just structures of data and should be treated like such when the need arises. Which brings us right to my next Good Habit.

Good:
Don't forget that the variable scopes in CFML are simply structures! (see above example). When working with dynamic variable names that can help a lot. It can also allow us to trash the evaluate() function for most of our code. It also means that we might want to use structKeyExists() rather than isDefined()...

Good:
Make your own variable scopes when working with a lot of variables. Many times we have a lot of variables that are related that can be grouped together logically. For example there may be several variables in a shopping cart script. We can put them all in a structure called 'strCart'. Now all of our cart variables are easy to get to in on structure, nice and organized - as if they where on the sme shelf. Now we have variables such as 'strCart.totalPrice' and 'strCart.shippingPrice' all under one roof. Take this one step further with the addition of shipping information. strCart.shipping might contain several values in itself such as package weight, shipper and cost that we can store nicely in the strCart.shipping structure like 'strCart.shipping.method', 'strCar.shipping.price', 'strCart.shipping.weight' and so on. Once you start organizing your variables on larger projects you'll want to go back and update old projects. It works that good! It really helps you're mind keep track of what's happening, and is even more helpfull in the future when that fix or update is needed.


A lot-o-nothin STORE (Demo & Test Area - but feel free to purchase - it's all really for sale!)

Check Page Ranking