This is a great topic and one of my pet peeves when it comes to other's
code and CFML in general. Because you can style your code in an almost
unlimited way, many CFML developers have. You can pick up 4 different
OS projects and find 4 different styles. You can open up a project you
have inherited and find as many styles as there were developers on it.
To me a sign of a good programmer is the style they use in their code.
Even though CFML has no "standard" style that doesn't mean one shouldn't
care. It very much pleases me to hear that others take pride in their
code and write for others in mind.
I'll give you the getID(), getId() example. The "ID" keyword is one of
those that will come down to a preference. I am mixed on this one.
Although I do not prefer it there is nothing wrong with using ID as a
column name and not prefixing it with the table name. Table names can
become long and I understand your approach there.
I do like the approach you mention of using fk_{tableName}_{id}. This
of course can become a pain when you have long table names. It is
always possible to reconsider the length of your column keeping
"readability" and "maintainability" at the for-front of your mind.
This also comes down to scale. In my case our scale is huge with many
developers ranging in skill and lengthy release cycles. The further
away you get from your code the more descriptive and meaningful your
naming conventions come in to play.
"Bryan, when you have a field like userID, does your user then have a
method named "getUserID()" or is it just "getID()"? I really like
having a standard "id" property on all my classes so that no matter
what object I am dealing with, I know it's primary key can be obtained
just by going object.getId(). This helps me to write slightly more
generic code."
I agree with you here. When I started refactoring my inherited
procedural application the first thing I did was create a Factory object
that initialized a bucket of objects on initialization. So for example
our entire Donor related code was encapsulated and placed into a Donor
object which then was initialized by the Factory. This object contained
methods such as getDonor(), getDonorID(), getDonorEmail(),
getDonorEmailID(), etc.
This of course quickly becomes large. So the next step is to further
encapsulate specific functionality such as moving all Donor email
related methods into a DonorEmail object. You then further break it
down from there. From within the DonorEmail object which calls the DAO
objects there are interfaces for methods such as getID(). Long story
short, yes it does allow you to have more generic code and I would
consider it a good practice.
Using request.location.url("aldfkjl") is good and I agree completely.
"Should it be about-us.cfm or aboutus.cfm or about_us.cfm?"
I always use and recommend using the underscore character to break your
words up in file names when they are to be called via an URL. If they
are privately included files I name them all lower case on the file
system but call them using mixedCamelCase. So if your side nav example
where to be called via the URL I would name it side_nav.cfm. If it is
not publically accessible I would name it sidenav.cfm and call it using
sideNav.cfm since it is included into my code and my code must be
"readable" and "maintainable".
"Although I suppose I could start seeing what those community frameworks
use for conventions and mix them until I have one I am happy with."
Since there really is no defined "standard" this is a good approach.
These of course are all good practices and up to your definition of
"readability" and "maintainability" in your context.
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf
Of Greg Stevens
Sent: Friday, June 20, 2008 12:46 PM
To: CFCDev
Subject: [CFCDEV] Re: Naming / Coding / Design Standards
@Mike,
I never thought of the possiblity of "sQLCommand" before. One thing I
have always assumed I was doing correct was always lowercasing all of
my starting word in a variable, meaning it would always be
"sqlCommand" in my mind. When I first read "sAMAccountName" I thought
you must have accidentally hit the shift key on your keyboard, until I
did a search and saw that really is how it's spelt ;)
@Mike, Bryan,
I am leaning towards getId() rather than getID() and having table
columns with "id" rather than "ID". I used to prefix the id column
with the table name for something like userID, but after finishing the
largest project I've ever done I decided that prefixing the id with
the table name is just extraneous. I got so sick of typing userID or
things like "missedSurveyResponseReasonID" (ya, it got that bad). For
foreign keys, I have a standard of "fk_{tableName}_{id}" so it results
in something like blogPost.fk_user_id.
Bryan, when you have a field like userID, does your user then have a
method named "getUserID()" or is it just "getID()"? I really like
having a standard "id" property on all my classes so that no matter
what object I am dealing with, I know it's primary key can be obtained
just by going object.getId(). This helps me to write slightly more
generic code.
@Bryan,
"URL" makes sense. Same with lowercasing it when variables start with
it, such as urlEncodedFormat(). I have been doing it this way but just
recently changd when I started wrapping all my href's with
#request.location.url("aldfkjl")#. I preferred all lower case there so
my code wasn't screaming at me all the time. I guess that doesn't need
to change though, since the function name starts lower case meaning it
should continue being lower case. so That's good. It stays as
#request.location.url("adlfjjlaf")# and if I had it different it may
be #Request.location.adminURL("someAction"). So that is good.
Variables being mixed camel case - I agree, thanks for clearing me up
and helping make a decision on it.
I completely agree with you on lower casing package names and all
files other than classes. I Have been torn lately about certain file
names though for public web pages. Should it be about-us.cfm or
aboutus.cfm or about_us.cfm? I understand Google searches "about-us"
as "about us" so that seems obvious to me, but than it becomes
inconsistent with private included templates like sideNav.cfm, I don't
really want to name that include side-nav.cfm. Any thoughts on that -
getting real off topic now?
I was using ColdSpring for a while but then switched over to LightWire
because I needed to do some more programmatic actions that were easy
to do in LightWire. I'm sure if I knew more than the basics in
ColdSpring I would have been fine, but I have been using LightWire on
all new projects and have been really happy with it. I need to try out
a more complete framework like Mach-II or preferably ColdBox. 1 Day I
will, but even when I do that, I would like to have these standards
down first. Although I suppose I could start seeing what those
community frameworks use for conventions and mix them until I have one
I am happy with.
So far from this, I think I can setup a few conventions that will help
a lot:
****
Convention 1:
Acronyms are upper cased.
Example:
URL, DAO, XML, HTML, HTTP
Convention 2:
Identifier is to be spelt "id" and not "ID"
Example:
id, userId, getId()
Convention 3:
Package names are all lower-case.
Example:
com.dao.oracle
Convention 4:
Variables are mixed camel case.
Example:
variables, this, form, url, client, session, myVar,
myObject
****
Still a bit more left to decide on (and not like this is set in
concrete yet). Would like to hear about me getting rid of the Gateway
for just a DAO and also having the DAO have a DataSource or Connector
of some type that just returns queries.
Thanks for the feedback! Great to hear how others are doing it.
Resources:
msdn Guidelines for Names -
http://msdn.microsoft.com/en-us/library/ms229002.aspx
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
