ColdFusion Coding Rules
Now that the first code checking application has been reviewed, I though it would be a good time to discuss the rules themselves.
For my entry, I just put together a few example rules. I looked to rules I would want to check for and turned to the list of rules for ActiveSoftware's CF Code Review Tool for inspiration. Mostly, however, I just tried to put together a few rules to demonstrate some of the capabilities of the tool.
Now that Ray has had a chance to review it, I would like to put together the first public beta as soon as I get the chance. In order for the tool to be realy useful, I need to have it start with a good list of coding rules.
To that end, I would love to get suggestions on what rules people think that a tool such as this should use (keeping in mind that the tool will allow you to add others as you see fit or have it not check for rules that are included).
To get the ball rolling, here are the rules that I included in my entry:
- Don't use a relative URL in cfschedule
- Use the accept attribute when uploading a file
- Avoid Evaluate()
- Don't start includes with /
- Avoid shared scopes in CFCs
- Prefer StructKeyExists() over isDefined()
- Prefer Len Over Empty String Tests
Who's first?
Remember the obvious: scope.your.variables and always use cfqueryparam for variables in queries.
It can be ambiguous because it starts from your site root and ColdFusion's determination of that can change based on a few factors (most of which I cannot now remember) and won't necessarily match the browser's determination of your site root.
Additionally, the use of a "/" mapping (which I think is a really bad idea anyway) will affect any cfinclude that starts with "/".
>> Avoid Evaluate()
Why? The screenshot mentions speed, but I've never seen any proof that Evaluate is slower than the alternatives.
Unless there can be proven benefits for not using Evaluate, I would argue that it's more a question of style so should really be "Prefer not Evaluate()" or similar.
Good point.
I debated about whether or not to list the rule as a "performance" rule (citing the speed issue) or a "maintenance" issue (citing readability). I think I chose poorly as I think the readability issue is much more important.
After all, I still like the quote "Premature optimization is the root of all programming evil." (Donald Knuth)
Actually, the full quote is:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
I agree that another wording might be more accurate, but then again it might be too long for easy readability. What do you think?
Otherwise very true, for complex evaluations, not true, it's actually quicker in this situation that other coding alternatives.
For me, readability is a bigger issue than performance. I find that structure notation is easier to follow than evaluate.
Perhaps that is personal preference?
Perhaps a footnote could be made about the complex evaluations bit though?