I know we each have our own styles and methods, but let me share the methods I use to create an application.
I'll put it into a checklist, because that's how I can make sure i got everything done in the right way and order.
1. Project Details: I really need to have as much information on a project as possible, because I don't want to waste time and energy on code, only to find out, it was nothing like what the client/end-user wanted. So get the details, ask as many questions as possible.
2. Project Plan: As you get into more complicated projects it really helps to plan everything out. There is a saying that sounds corny but really works in the real world. "Plan to Work, Work to Plan". The project plan can be simple to complex, but the more effort you put into it, for the simpler projects, the more prepared you'll be for the complex ones. This can involve using a ms word template, notebook paper, flow charts, wireframes, etc.
The other benefit is that if you store this plan you can refer to it, for future changes to this application, so you can a better idea of the thinking behind each project.
3. Dev Enviornment: Where am I saving the files to? What folders, server etc. And how can i test and debug the application? Do I have access to cfadmin for easy debug? Make sure your setup so, you can go to coding.
4. Comment Header: Basically name, description, author, manager of this project/application. Include version number, dates/times, more details is better. Because not all the time you'd be working on new applications, there is always new changes/fixes/features to be done to existing applications. So prepare the way by having a detailed comment header.
5. Comment out what each section of the application will be. Before I code each section, I create sectional comments to help indicate what code needs to belong where, to make sure I know where to put each code, and i describe what each section does, and I use indents as they would be when I add the code beneath them.
6. Now I work on incoming and outcoming variables. Over my experience in issues with scoped variables, and isdefined or parameterexists, I have my own system and naming system to help me control and simplify incoming data.
I always create a cfparam for any possible variable, and name it like local_first_name. Even though the form field may be form.first_name.
Then I have default blank values for all of them, unless they need to have a special value.
Now I no longer have to check for the existance of variables, and then there values, now i only check for values.
In the past you had to do
cfif form.first_name eq "Craig"
Now I can do
cfif local_first_name eq "Craig"
Now before I can use these local_ variables, I still have to populate them.
And this is where I can get into more specific control of scope priorities.
I can say that I want an url variable, to pass value more than i want a session variable to pass the value.
The reason for this extra detail into scopes, is because if they have the same name, they can be over-written without you being aware of it. (Because at some time I had this horrible application that variable named clk, that was being populated by a bunch of different scopes with no scope specificity or prioritization.)
So we have a cfparam variables all populated, if you use additional variables, please add them to the top section with all the cfparams.
7. Logic, now i go over all the logic that I have to go thru, what kinds of conditions, simple or complex. If simple I stick to using CFSWITCH & CFCASE because they are faster than cfif, but if it is complex, i stick to CFIF.
8. Queries / SQL Code, here is where I go thru a similar checklist.
A. Use a sql tool to generate the data, you'll need for each query, and then put it into the order you want. Select * is a definite NO NO. It is better for performance and scalability if you stick to what fields you want from what tables.
B. Once I have the data for each query I want, then I convert it into the dynamic queries, and use datatype validation via CFQUERYPARAM and CFPARAM to make sure data sent to databases is exactly what we want. CFPARAM has an additional but not well used paramater called type, so that as you copy from different scoped variables to the local_ one or whatever naming convention you use, then you can make sure it's the right type. In addition CFQUERYPARAM also has a CFSQLTYPE to make sure of data type. You should at least use one way of data type validation, for security sake.
C. Performance Analysis, I look at the CFQUERIES in debug info, for times that are over 250 milliseconds. I verify that each query is only bringing the data in terms of fields and rows that I need. I make sure there is no looping of a cfquery because that is very bad for performance, and there are other faster ways to grab data. I look for queries that should be converted into VIEWS, if they are multi-table joins or complex sql code, then they are open to being converted.
9. Error Proofing, no matter how hard we work, there will always be errors, so now I double check my variables, logic, queries, then look for areas that might crash, and then i put CFTRY/CFCATCH. Make sure that there is a custom error page, to re-direct to, to make sure the user feels we are professional in how we handle our errors. I'd rather spend the time proofing and preparing, then having to explain an error to them that cost them a lot of money.
10. Functional Checklist, now I start looking at all the project details to come up with a checklist of how to determine if this application does everything that it is supposed to do.
Once you feel you did everything right, then hand it off to someone else who has not seen the code, and have them go thru the functional checklist. Become expert in helping others break applications, because if you get that knack during development, you'll develop the instincts and skills to prevent repeating mistakes.
11. Schedule the release of the application to production after it has been approved.
How do you create your applications?
I always make sure I have as much details about a project as possible. I don't want to repeat the experiences of wasting time and energy, only to find out I was no-where near where the end-user wanted me to be.