*Here are my two cents:*
*On the subject of "Premature Optimization": I agree with Dave that as
developers, sometimes our tendency to create "clever" code could result in
cryptic code, albeit "short". That said, I also believe there are definite
lines between decent and sloppy code. For example, I was working on a
legacy application recently and there were lines of code like <cfif a is not
"" and a is not " " and a is not " ">. (What it meant to say is <cfif
LEN(TRIM(a))> ). So, the real question is--when is it best to optimize?
Personally, my rule of thumb has been "do not reinvent the wheel". If there
is a native CF function or tag that can be used to get your idea across,
then by all means use it. That is probably an overly simplified view, but it
is a start. *
*On the subject of using the database to store calculated date values:
Assuming the shipping date calculation is the only one you would be doing on
a regular bases for this application, I think it is a bit of an overkill.
However, there are situations when doing that is a good idea. For example,
I used to work for a company with an application that processes
payroll-related data. As such, it constantly needs to refer to X business
days before or after current date. *
*Now, on a microscopic level: *
When I suggested the UDF BusinessDaysAdd(), I had meant it for that block of
code to set the NewDay value, which does not include Saturday as the new day
(delivery date). So you could rewrite it as: <cfset variables.newDay =
BusinessDaysAdd(NOW(),2)>
As for the loops... Is the inner loop for query qryGetShipCosts really
necessary? For each shopping cart, your query should retrieve only one row
from the database--one shipping cost for each delivery date option, correct?
If so, get rid of that loop and just refer to #qryGetShipCosts.NextDay# and
etc, like the following:
<cfloop from="1" to="30" index="i">
<cfif DayOfWeek(variables.newDay) NEQ 1>
<li>#LSDateFormat(variables.newDay, "mmm-dd-yyyy")# -
#DayOfWeekAsString(DayOfWeek(variables.newDay))#
<!---Next Day Delivery --->
<cfif i EQ 1>
<strong>#qryGetShipCosts.NextDay#</strong>
<!---Two Day Delivery --->
<cfelseif i EQ 2>
<strong>#qryGetShipCosts.TwoDay#</strong>
<!--- All other delivery options get standard price unless it is for a
Saturday. --->
<cfelse>
<cfif DayOfWeek(variables.newDay) NEQ 7>
#qryGetShipCosts.Standard#
<cfelse>
#qryGetShipCosts.Saturday#
</cfif>
</cfif>
</li>
</cfif>
<cfset variables.newDay = DateAdd("d",1,variables.newDay)>
</cfloop>
*Finally, a couple of personal habits if I may be so indulged to go on...*
*I always include SELECT TOP 1... in a query if I expect that query to
return one and only one row. I think it makes it clearer to the reader what
is to come. *
*I have an obsessive compulsion to scope ALL of my variables. I think it
makes your code far more readable and easier to maintain. In your code for
example, if the reader sees the line of code <cfset newDay = ...> they will
probably guess NewDay is a local variable. However, it is still nice to
explicitly scope NewDay everywhere so wherever the reader's eyes land first,
he/she knows it is a local variable. I know the CF books tell you
*sometimes* it is a good idea not to scope variables because it makes your
code more flexible. There are certainly situations where that is true. For
example, maybe you have a page that expects a product_id to display a
certain product, and this product_id could come either in FORM or URL
scopes. However, I am not convinced this flexibility is worth it at the
cost of readability. You could always cast your URL scopes in FORM scope
either by way of some JavaScript or through settings in a framework like
Fusebox. *
Just a few thoughts... [?]
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Want to reach the ColdFusion community with something they want? Let them know
on the House of Fusion mailing lists
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:329740
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
