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

-------------------------------------------------------------


Reply via email to