My biggest pet peeve: CFQueries inline in a CF template. I'm not a stickler for complete object oriented or "you have to do things exactly a particular way"...that being said, I have two reasons why I like to see cfqueries or cfstoredproc calls in a cfc or a cfm template that can be called as a cfmodule:
1. You know where to look for the code - if you do it in a cfc, you can have all your data access calls in one place that is easy to find in various methods 2. If you're writing a query to be used on a page somewhere, chances are, you'll need that same query again somewhere else - this doesn't always stand true, but 9 times out of 10, you use the same general queries for multiple areas on a site. My second biggest pet peeve: Looping over a query just to query x number of times again. This is probably the thing that I see beginners do the most, probably because they just don't understand how to write a query to retrieve all the data at once. For instance, someone might want to see their top 100 customer's orders..a lot of times you'll see someone write a query to retrieve their customers, and then loop over that query and then query to get the orders (so basically 101 queries to the db)...in reality, all they had to do was a query from the customer table left joining the order table in one query, and then looping over the results with a group by. The last one I can think of this early: Using CF as your paging repository for large datasets...this is probably the fault of many a book and message board out there, and probably just having the feature available in CF makes it too easy to pass up for most. But, the ability to query a db, retrieve 100,000 records, and then just using records 10-20 or something like that. I hate seeing that. The amount of network bandwidth being utilized, the memory being wasted, the processing required from cf, etc. It's just a horrible thing to use. I cringe every time I see it...and if I have my hands in it...I change it immediately to do a db implementation to just retrieve the rows needed. ________________________________ From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Derrick Peavy Sent: Monday, January 04, 2010 9:07 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Examples of How NOT to Code in ColdFusion? <!--- ============ MY FIRST PET PEEVE ============ ---> <!--- people need to learn to comment their code ---> <!--- for example, when I have to throw in a hack, i like to remind myself to remove it ---> <!--- so I type: "hey dumba** - remove this comment and code block as soon as you can figure out how someone is loading this page, four screens deep in an app without any client or session vars enabled in the client when it should be impossible and the page will not even load when tested by 20 different browsers in 7 countries" ---> <!--- I have an important file in my app that is probably 50% comments. seriously. because it's an awesome file and elegantly simplistic and responsible for 50% of the data on the site, so it's nice to be able to go back when tweaking and know why something is done the way it's done. So, maybe 350 lines of code mixed with xhtml and another 350 of comments. overkill? yeah. But if I die, you won't have to guess! ---> <!--- just to check myself after your post, I looked over my app.cfm file, I have a total of four (4) client vars, two of those can be int(11), one can only be a single digit, and one can only be either "Y" or "N" ---> <!--- there are some application variables for things that never change and so they can persist across any client or time up to the max allotted time for app variables to expire ---> <!--- everything else is session with a reasonable time out setting ---> <!--- not unusual to have 100k page loads total considering all bots and spiders and users, and 7 or 8K user page loads in a 24 hour period with no cpu spike or lag time unless a background data process is scheduled ---> <!--- ============ MY SECOND PET PEEVE ============ ---> <!--- writing every gosh damned query as a fricking cfc ---> <!--- the beauty of CF is that you can actually just write a da*n query and just run it ---> <!--- which brings me to... ---> <!--- ============ MY THIRD PET PEEVE ============ ---> <!--- people who can't accept a database structure that gets the job done without 100 x-ref matching tables which require 42 queries to get a user name and email ---> <!--- stop it. just stop it already and learn how to make data simple and accept that you are not Aamazon and you will never, ever, ever, likely scale your app beyond a few hundred concurrent users accessing the minimal amount of data ---> _____________________ Derrick Peavy derr...@derrickpeavy.com<mailto:derr...@derrickpeavy.com> 404-786-5036 "Innovation distinguishes between a leader and a follower." -Steve Jobs _____________________ On Jan 4, 2010, at 7:12 PM, Cameron Childress wrote: On Mon, Jan 4, 2010 at 5:18 PM, Derrick Peavy <derr...@derrickpeavy.com<mailto:derr...@derrickpeavy.com>> wrote: So, five session vars, numeric in value, less than four digits (or single char values), along with multiple client vars of less than 4 digit numeric values or single chars - you're saying that's a huge eff'n no?? I ask because at even 10,000 page views a day, I see no performance hit at all. But then, maybe if I change it according to some rule, I would see average CPU loads of 0.004 instead of 0.04?? Well, considering the relatively low load, and low number of variables, I don't know that it would have a significant impact in your case. Like I said, there are always exceptions. Nine times out of ten, however, when I see both client vars and session vars both enabled in an application, it's for no good reason at all. What's on your list of no-no's? -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------