@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
-~----------~----~----~----~------~----~------~--~---
