Comments are good, but you may be going over the top a bit from what
you're saying ;) But there's no hard and fast rules on that point. in my
experience, if you are using a known framework, good design patterns and
unit tests - heavy commenting isn't usually needed as much. I tend to
see the need for heavy commenting when the code gets highly esoteric.
John
ma...@fusionlink.com
twitter: john_mason_
blog: codfusion.com
Derrick Peavy wrote:
<!---
============
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
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> 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
-------------------------------------------------------------
