EasyCFM.COM ColdFusion Forums / Good Coding Tips! / Naming Conventions

   Reply to Discussion | New Discussion << previous || next >> 
Posted By Discussion Topic: Naming Conventions -- page: 1 2

book mark this topic Printer-friendly Version  send this discussion to a friend  new posts last

dduck1934
12-18-2006 @ 12:05 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Senior Member
Posts: 264
Joined: Sep 2004

Hey guys,

I am wondering what naming conventions you guys use for your methods, variables, form fields, queries, compnents etc. I realize its all personal preference, but I wanted to know what has worked for you?



I feel my luck could change...Its gonna be a glorious day.

JJfutbol
12-18-2006 @ 12:23 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Moderator
Posts: 1250
Joined: Nov 2004

Ah well done El Pato! Smile  This should prove to be a useful topic for everyone. I always aim for descriptive naming over shorter names. Although with keeping things simple I might end up with not such a long name.

For methods that work with booleans I like using the word 'has' or 'is' at the beginning. For example, hasID() or isRegistered(). So if I'm doing something like this:

<cfif variables.user.isRegistered()>

I find it much more readable and usually doesn't ever require a comment. Also despite the great use of the hint attribute (generated cfc docs) I find it not worth the effort if function and variable names are meaningful as they should be and tell you exactly what they are. Trust me this is critical. Oh the horrors I've experienced with other languages. Smile  I love my 'findNoCase', 'find', 'reFind' and just despise 'eregi' (what the hell does that mean PHP? come on!).

Also for boolean type variables I like to have the 'is' or 'has' in front of it. For example, <cfset isActive = true> but I've noticed I'm not one that likes to put data type indicators in front of a variable name (arr, st, etc. - exclude queries) not sure why but I just find it more readable without it. I usually can always tell what data I'm working with. So for example with date/time variables I prefer something like this:

<cfset createdOn = now()>
<cfset updatedOn = now()>
<cfset eventStartsOn = now()>
<cfset eventEndsOn = now()>

For queries I'm still stuck with the habit of throwing a 'q' before whatever it is I'm returning. I've seen many use 'get' or other keywords I guess for me its just a matter of I haven't been able to ditch 'q'. For components I try and keep the name within 1 or 2 words and for my beans the name stays singular. Anything else I just try to keep it descriptive.

----------------------------------------------------
Some free CF applications available at my site, such as the popular CFC Validator www.javier-julio.com My new site design is up!! Let me know what you all think! Working on a fully accessible Forum, which validates as full CSS and XHTML 1.0 Strict.

This message was edited by JJfutbol on 12-18-06 @ 12:25 PM

twista
12-18-2006 @ 12:42 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Senior Member
Posts: 232
Joined: Jun 2006

Databases:
Table Names: CamelCase(first letter capitalized), singular form, descriptive of contents in as few words as humanly possible. So, for a table of calendar events. I would type CalendarEvent as the name.(Be careful with singular naming in a database, very easy to run into reserved words. ie. User)
Field Names: Descriptive of contents, CamelCase(first letter capitalized). CalendarEvent.EventDate

Objects: I name it for the functionality it contains. CamelCased with the first letter capitalized. Internal methods should have a camelCase with the first letter lower case. User.doUserLogin(). Properties(in the variables scope of the object) should be camelCased with an underscore(_) in front of them: _objectProperty = 'value'.

Functions: I like to name them for specificity in camel Case with the last first letter lower cased. Name it for what it does. like so: getValue() setValue() doLogin()



-------------
-Morgan
Lead Trainer of the Ninja Squirrels
quote:

every time you store comma delimited values in a relational database, God kills a kitty.
-CJ

SirRawlins
12-18-2006 @ 1:24 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Moderator
Posts: 951
Joined: Mar 2006

Yes this is a nice topic to discuss.

When I first started out in CF earlier in the year, I found it a great help to prepend everything with a referance to the type of item I was dealing with, so.

arrMyArray - Arrays
strMyStructure - Structures
qryMyQuery - Queries
tblMyTable - Tables
objMyObject - Objects

And a few others I forget.

However, as you become more comfortable with the syntax it actualy becomes easier to read when you drop all those prepends and just work with the basics of naming.

Like JJ says, clarity is the key, keeping things relevant and description of what the item 'is' or 'does' are very important.

For multiple word names, use the camelWhatever that was suggested by twista.

Also keeping all your components/objects with a capital letter at the start is meant to be a good thing, and apparently is suggested as a best practice in other programming languages aswell.

Although, even with great naming conventions, you should always use the self-documenting hint attributes ... thats just JJ being a lazy bones ;-)

Rob

dduck1934
12-18-2006 @ 2:03 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Senior Member
Posts: 264
Joined: Sep 2004

When i see strXXX i think string and not structure, but that is just me.  What about form variables?

things like

textfields = txtFoo
textarea = taFoo
radio buttons = radioFoo
checkbox = chkFoo
buttons btnFoo


What about component names?  Do you guys do anything special naming them?

mycfcDAO = Data Access object
mycfcBean = CFC Bean
mycfcGateway = CFC Gateway object
mycfcFactory = CFC Factory Object

dduck




I feel my luck could change...Its gonna be a glorious day.

JJfutbol
12-18-2006 @ 2:24 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Moderator
Posts: 1250
Joined: Nov 2004

I can see it being helpful for having unique names in something that can have multiple values such as checkboxes or multi-selects. As of now though I just use a plural name to best describe. So if I have a set of checkboxes that ask for the user's favorite sports. I'll probably just simply call it favoriteSports. I've never been one for adding data types or just plain types to variable names but in a team environment they can be quite beneficial.

I take it then by component names you don't mean their file names. I had originally assumed that so my bad. For objects I don't do anything special either but I know many that do. For example, I know developers will place 'obj' before all their objects. When I first started doing that I had thought of putting 'gwy' in front of the object name. So for example:

<cfset variables.objUser.someFunction()>
<cfset variables.gwyUser.someFunction()>

But here at work developers prefer to have their component variable names the same as the file names. So for example if we have User.cfc, UserDAO.cfc and UserGateway.cfc we would have the same as variable instance names for those objects.

----------------------------------------------------
Some free CF applications available at my site, such as the popular CFC Validator www.javier-julio.com My new site design is up!! Let me know what you all think! Working on a fully accessible Forum, which validates as full CSS and XHTML 1.0 Strict.

dduck1934
12-18-2006 @ 2:41 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Senior Member
Posts: 264
Joined: Sep 2004

yes JJ,

sorry i wasnt clear, but I was talking about both.  If you guys do any special naming of your cfc files.  I have put DAO for me to know thats my DAO (duh), but also I was talking about when you call them in variables.  I have used obj as a prefix in the past, but I dont have a set way I use for components.

variables.objFactory.createUser('matthew')

thanks guys.  

dduck


I feel my luck could change...Its gonna be a glorious day.

twista
12-18-2006 @ 3:42 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Senior Member
Posts: 232
Joined: Jun 2006

I don't prefix my variable names because CF is a typeless language, so your variable types can change from string to integer quite quickly. I find that if I have a situation where I might need to know the variable type for certain than I suffix it. userArray, ValidationObject, joinedDate.

For my objects, I try to keep the first letter of everything that isn't in a database or object lowercase.

So I know that if I see an uppercase letter that it's something more complex.


-------------
-Morgan
Lead Trainer of the Ninja Squirrels
quote:

every time you store comma delimited values in a relational database, God kills a kitty.
-CJ

Lossed
08-01-2007 @ 7:22 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Senior Member
Posts: 1095
Joined: Apr 2004

How about referencing literals? Single or double quotes, context-dependant, or?

Lazy@ss here uses single quotes mostly because it avoids having to hold down the shift key Smile

Lossed
---------------------------
When the only tool you have is a hammer, everything looks like a nail Smile
-----------------------------

aadams
11-14-2007 @ 6:33 PM
Reply
Edit
Profile
Send P.M.
My Gravatar!
Powered by Gravatar
Senior Member
Posts: 280
Joined: Nov 2005

This is a good topic, and I've meant to post on this many times, but always find myself preoccupied with all this work stuff.

Anyway, just to throw in my 2cents (since my style differs slightly from those above) here are a few rules I code by (your mileage may vary):

== DO's ==

Tables names:
- plural if it contains multiple records, single if not
- all lowercase delimited with underscores if more than one word.  Example: order_items
- cross reference tables (many to many) I combine the name of both tables with _to_.  For instance users_to_groups

Table column names:
- Primary key always ID (caps)
- Foreign keys always table_name_ID (ie. users_ID) (ID in caps)
- words delimited by underscore (like table)
- Date/Time fields appened _datetime
- Boolean fields begin with is/has

CF Code:
- variables: camelCase (don't use underscores, this helps differentiate table columns with variables)
- functions: camelCase, describe action (getUsers, setProperty, writeFile, etc...)
- prepend is/has on all boolean variables or functions that return boolean
- Uppercase all constants (use underscores for multiple words, ie: STATUS_ACTIVE, STATUS_INACTIVE)
- Don't use #'s unless I have to. (bad: <cfset this="#that#">, good: <cfset this=that>)

Form Field Names:
- If related to a column in a DB I use the column name

SQL:
- Uppercase all SQL operations (ie: SELECT FROM WHERE)

CF Files:
- include templates for presentation layer prepend with dsp_
- include templates for logic prepend with inc_

== DON'TS ==
- prepend datatype info on anything (str, int, etc...)
- prepend "tbl" to table names
- use spaces in variables, tables, columns, anything.

This is not all inclusive, but is a general overview of how I name things.

Once apon a time I pulled down a "best coding practices/coding standards" document published by Macromedia (or was it Allaire?).  I heavily tweaked this document as time went on and use it to guide new developers in our team (as well as a refresher when I get sloppy Wink ).  I think this is a good idea, no matter what style you prefer.


--Abram
CFXChange.com - ColdFusion Custom Tags and Components

PAGE: 1 2

Website Designed and Developed by Pablo Varando.