3 Replies - 2136 Views - Last Post: 31 January 2011 - 04:15 PM
CF Best practices
Posted 31 January 2011 - 09:30 AM
This topic isn't about that.
I want to ask your opinion about what CF best practices should be. I'm asking about things like code spacing, tabs, spaces, commenting, general .cfm layout, order you do things, and anything else that you like to see. We all have our own habits for how we code but what I want to know is: how would you define "best practices" when it comes to opening a CF page you didn't code?
Like for instance: today I got handed an old module to update. This thing was built by two contractors several years back to access and parse the take from a third party web service API. I open up the page the scheduled task calls (this thing is supposed to run on a set schedule) and was pretty much horrified by what I saw. Zero commenting, huge run on lines of code such that my Eclipse on 1680px wide STILL needed to scroll right and left to view code, and the needless CFINCLUDEs. Egad. For a page of just 150 lines...EIGHT separate includes...and for no discernible reason whatsoever. It was like it was built to intentionally frustrate any later dev tasked with looking at it.
Replies To: CF Best practices
Re: CF Best practices
Posted 31 January 2011 - 09:56 AM
1. Comment, Comment, Comment
Now I know that everyone says this, but it is still extrememely frustrating to find under commented works. Now I am not a super nazi that feels that every line needs to be commented.
For example here is a line of code that does not need a comment
// Easy to read totalItems = doAddition(totalItems + amountNewItems) // Hard to read /* Take total items and add the amount of new items to that to recreate totalItems variables */ totalItems = doAddition(totalItems + amountNewItems)
The second example isn't actually that difficult to read, but imagine a bunch of calls like that. I think the first example is extremely easy to read based on variable and function names personally.
2. Name your variables well
Variable naming is important and I suggest that everyone figures out a naming convention that works for them. My using convention is that if the name of what the variable holds is too long then take the vowels out. Also make sure to name variables and functions according to what they do
// Easy to read var arrayUsers = getUser(23); // Hard to read var a = z(23);
3. Separate Business from Play
This is one thing that I had a very tough time with until I started working with other designers and I think developer who, like me, also do the design are all going to have a tough time with this. The important thing to remember is that you want to be able to pass your application off to a designer and another developer and if they can work without over writing eachothers code then you have done a good job. Avoid running inline queries or creating functions on your display pages. ColdFusion has CFC's for a reason. If you don't know how to use them then you damn well better learn.
I have tons more, but I don't have time right now to add them. I will try to later though.
Re: CF Best practices
Posted 31 January 2011 - 10:13 AM
Funny thing is, I discovered not too long ago that how you name your variables can be quite important. I found while working with an app that had queries against a MySQL database, that the table and column names were case sensitive. So, if you had a column called "userId" in a table called "Users" and you tried a query like so,
SELECT userid from users(like I did), it would fail. What's even better is that the error message CF displayed was entirely unhelpful as it would say something like table "users" not found and I'd go into the database and see Users sitting right there and I'm going "WTF"? That took way longer than normal to debug because it's not something that happens when you use SQL Server (which is what I was porting it from).
Anyway, since then I've decided to go with the same naming conventions across the board for my CF variables, JS function names and variables AND database tables and column names. Makes life much easier.
Re: CF Best practices
Posted 31 January 2011 - 04:15 PM
As I promised here are some more best practices
4. The wheel already works really nice... don't reinvent it
Recently, I have found that being a one developer shop with a lot of projects means that I can't develop everything myself like I used to. Many open source libraries and even full applications already exist, and so long as they are being kept up to date, or you can keep them up to date then use them. That being said, do keep in mind licensing of those applications.
5. Frameworks, Frameworks, Frameworks
When I say frameworks, I don't mean to go out and learn Mach II, or Model Glue, or any the thousand others necessarily. I mean to organize your code into a method that you and anyone else who will potentially work on this project so that you can find what you are looking for. That being said, I do think that learning at least a simple framework like FW/1 is a great idea. FW/1 is an MV, no xml, near no config framework that at it's most basic organizes your code into controllers, views, layouts and services. The documentation is great and it is really simple as a first framework.
6. Release Open Source Applications As Often As Possible
This is my last practice, and it really isn't a best practice. In my past 2 years of professional development I have learned a lot of stuff on my own, but it is impossible to learn everything from a book. I try to release open source applications on my own as often as possible to 1. add to the community and 2. see what other people say about my coding techniques. Understand that not all companies allow you to release open source stuff, so check with your company before going nuts with GitHub.
So thats my best practices. I have others, but I think 6 is a good starting point for this thread. Do keep in mind that my best practices are just that... my best practices. They may not work for you and I think that regardless of what the community says (to a point) you should define your own practices that work for you.
Also I think this should get pinned so that people coming into the community can see best practices that more experienced developers follow.