I totally understand where you are coming from...
Code Divas Unite!! Maybe some good "best practices" documents could come from such a discussion amongst a CF Code Diva Committee???

Food for thought...

Mmm Hmmm, code diva's unite.

Being a code diva, to me, is the difference between a Hobbyist CF developer and a Professional CF developer.

Everybody loves Raymond.

I like to use <cfcontent reset="true"> in order to suppress white space ... Rockin' Ray (pic )... nice :-)

A hem ... Pardon me, I meant ... Rockin' Raymond ...

Heh, I should give credit where credit is due. The pic above comes from Edward. (I'm just happy he used the newer pic of me. ;)

I guess I'm a code diva, then.
Hungarian notation - definitely no, but certainly lowercase variable names with capitals where you want to show new words. I always insist on <cfset var local = structNew()> in my functions, for instance, but God it makes debugging so much easier!
Whitespace and tabs, check.

Perhaps diva-ship comes with seniority and experience?

Tabs all the way. My business/coding partner and I a got in a huge fight about tabs vs spaces a few years back until I showed him the way. He was all like (adam sandler voice) "spaces are better, they make the code look all nice and clean" and I was all like "tabs are better, they make the code byte size smaller and make switching IDE's easier". So as you can see. I showed him.

check out skinny ray! That picture is begging for the greatest american hero suit to be slapped on it. You photoshoppers get busy.

output="false" should be mandatory due to problems that can occur with returned data when you leave it off. I wish there was an option in CF Admin to set all cffunctions to output="false".

I've got a series of Regular Expressions that I run over my team's code to make sure it adheres to the coding standards we adopted. For example:

Wrong: <cfset foo = "" >
Right: <cfset foo = "" />

I'm totally with you, Ray. Except for <cfsetting enablecfoutputonly.... I try not to use that one if I don't have to since it always seems to bite me in the tush at some other point. I usually use <cfsilent> which means more lines of code, but seems to fit my style.

Tabs only, with spacing set to 2 spaces, not 4. Proper indenting. Clear separation between code blocs with appropriate white line usage.

I hate it when there is a 500+ line code with absolutely no white line spacing. You've just made me take my time inserting returns so I can find that darn bug, thank.

@Adrian

"I've got a series of Regular Expressions that I run over my team's code ... "

You Qualify ... :-)

Now, see. There's nothing wrong with Rocky Horror. They used to run this in Allentown, PA back a few years. I too have started to come into the camp of <cfsetting> everything silent and then just cfoutputing what's required. Makes a huge difference when calling things like <tag:something> and CFCs.

Code Diva??? Hmmm... Does "Code Nazi" count? I've been called that by the junior programmers on a great deal because of the way I tend to "nitpick" their coding "conventions" such as they are. Hungarian Notation - no I don't push that - but certainly a standardized naming convention with lowercase (camelcased) variable names - properly scoped of course.
Indents - check. Tabs - check. Appropriate Field and Table naming conventions in a database as well (Tables always start with "tbl" and Fields should always start with "fld" so things are easily identifiable).

@edward... dude seriously... thats extreme... (any chance you can share those??? but let's keep it on the dl... ok)

indentation is my biggest, but i'm still not comfortable with how to seperate cf tags from html when it comes to indenting (i was thrown into cf about 15 months ago). for tags that have attributes that extend past my personal page wrap, get a cr and indent... and then have the closing bracket on its own line... lined up with the opening bracket (wierd i know)

don't know how to describe this one:
<cfset var bob = "bob">
<cfset var jimmyjoe = "jimmyjoe">

trailing whitespace - these are no no's. if i see them, then they must be eradicated.

i_think_everything_should_be_underscored

more than a code diva, i think i am an app diva. that's really where all of my quirks tend to reside. i've got a few first love apps that everything else gets ranked by. i can hear cfe saying in a high sassy voice: well crimson does it and it hasnt been updated in 4 years.. i'll tell you what i think about crimson...
;)

Well, I'm certainly a diva when it comes to database stuff. I can't tell you how many developers I've PO'd over the years by renaming tables and columns -- after they have written code against their own names.

Even worse is when see database structural/design errors long after coding has begun. mea culpa... should have looked harder, earlier.

off the cuff, my rules would include these...
- table names should be plural (customers, not customer).
- every table should have a autopopulated column called create_timestamp. CF developers must ignore this, and let the database provide the value.
- column names and table names are all lower case, and words separate with underscores. (underscores are no better than dashes, or camel case, but the others are no better either. )
- db tables should have only one primary key -- and almost always an automatically generated integer. Generally, the primary key should be table name + '_id'. (e.g. customer_id)
- with the execption of the primary key, there is generaly no reason to repeat the table name in column names. (you should not have a column name 'customer_name' in the customer table -- 'name' is sufficient.
- don't over normalize.
- If CF is your applicaton platform, you gotta use CFCs to access the db -- because we may change the db structure tomorrow for business reasons, and we don't want to have tell the business users that "we can't really do that in a reasonable amount of time"
-- thats a start... one more beer and I'll by grinding them out all night.

My rationale is that the right choice of application languages such as CF and Flex and PHP (for you two) change over the years. So too IDEs. But SQL databases have been around for a very long time, and will likely be around a whole lot longer. Database is the place to be a diva -- CF, not so much.

And, admittedly, many of my rules have no better foundation than "that's the way we've always done it, and the arguments for consistency are currently stronger than the arguments for changing the standards." (therefore, my standards don't apply to your shop, and therefore, its pointless to debate them. And the corelary is -- new programmers should not bring the baggage of their history into my shop's applications-- it has enough baggage already ;-))

Ron

I'm like an OCDiva.

My hands were built for ridiculous speed, so apparently I do things pretty differently (read: better) than normal developers.

I shoot for obvious, explicit, if-need-be-ridiculously-long variable names. "Usually" prefixed with their type.

<cfset arrayQualifiedOrganizations = arrayNew(1) />

If your prefixes are written in legitimate English, there's no guesswork or memory-recognition necessary. Meaning you can work with the same code you are now when you're 80, without having to use Alzheimer's as an excuse for not meeting a deadline.

I don't have to worry about whether aQualifiedOrganizations connotes an array or the English article "a", or whether arrQualifiedOrganizations was shorthand for array or just a mistyped boolean (areQualifiedOrganizations).

I don't have to think, I just have to know how to read. And if, perchance, you read quickly, it's not only convenient but becomes much faster than the overhead of memory-recognition and saving yourself x keystrokes.

This is where I start to sound crazy. I make other developers use the same IDE (Dreamweaver CS3--8 is acceptable if you're a die-hard Luddite), file organization strategy, and EVEN CODE COLORING and font. If I sound like a communist right now, it's because this particular paragraph was a joke.

I do, though, demand that other developers follow my COMMENTING patterns.

The flyest of which (which I never see anyone do unless I have a gun to their head) is to preface each organizational element type with a
<!--- f: functionName --->
<!--- div: divID --->
<!--- cfif: condition --->
<!--- cfelse: condition --->

And end it with a
<!--- xf: functionName --->
<!--- xdiv: divID --->
<!--- xcfif: condition --->

This can become SUCH a powerful tool for flying through large hierarchies of code if you use bold-backgrounded code coloring (only available in Dreamweaver, CFEclipse can't handle it).

Being able to glance at a 30" monitor's worth of code and imemdiately see how far the current cfif block goes and which cfelse belongs to it is so powerful, and your eyes just can't do that without the comments.

Adrian: The regular expression thing is AWESOME. HOLY CRAP. I'M IMPRESSED.

I drive my fellow developers nuts with my puritan way of coding. And I'm allergic to whitespace in my HTML ;-) Except where needed of course for nice indentations! Most of the things you describe I do too. For production machines I usually run a script in the Application.cfc that strips ALL whitespace from the code, generating a minimal footprint - it does mean that inline JS needs a CDATA block, otherwise that will break. On developer boxes I share with fellow developers I have lately let off a bit on my principals in the nature of keeping the peace. So yes I should be considered a diva, but also a Standardista.

I'm a diva in ways (Hungarian notation / camel case), but it really bugs the crap out of me when people think cfml is xhtml.

I don't like to force my tendencies on anyone, but I know I have some:

I hate that people think tags should be closed - but I do it myself - and there must be a space before the trailing slash.

<cfset foo = goo />
not
<cfset foo = goo/>
oh - also - there needs to be spaces before and after the = - so none of this either:
<cfset foo=goo />

I get into habits where I like to see attributes in a certain order - for example:

<cfinput type="text" name="foo" value="#foo#" />

or

<cffunction name="foo" output="false" access="remote" returnType="ray">

I like indentation - a lot. Every nested tag should be indented with a tab.

And whitespace - in certain places. For example, before and after each cffunction should be a line of whitespace. Pretty much everywhere there is a logical mental break in the code I want to see a space. After arguments (and vars) are declared, etc.

PS -- Dan Vega called *you* a code diva? Is this the same Dan Vega that spent days working on his blog so that the *generated* HTML looked good? :D

I am a HUGE code diva :)

I am definitely accused of coding like a girl. I wrap my cffunction attributes, align my = signs, attributes, etc.

(I am not sure if the spaces will show up correctly when this is posted, but will try)

<cffunction name = "testFunction"
access = "public"
output = "false"
returnType = "boolean">
<cfargument name ="uID" type="numeric" required="true" />
<cfargument name ="uName" type="numeric" required="true" />
</cffunction>

In CFEclipse, doing the above helps because when you open a component with code collapsed, you only see the function name line, making navigation through lots of code very easy.

In CF, I like to align my cfsets so that the var, = and "" align, and follow the "space before/after equals" idea. I also like to have all singleton tags end in /:

<cfset var name = "" />
<cfset var longerName = "" />
<cfset var wayLongerName = "" />

In Flex, I would do this with the : character
public var name : String;
public var longerName : String;
public var wayLongerName : String;

There you have it, I code like a girl. Very anal indeed, but I like it.

Damn! It didn't work. The above code should have been aligned differently. Maybe pre will work?...

<pre>
<cffunction name = "testFunction"
access = "public"
output = "false"
returnType = "boolean">

<cfargument name ="uID" type="numeric" required="true" />
<cfargument name ="uName" type="numeric" required="true" />
</cffunction>

<cfset var name = "" />
<cfset var longerName = "" />
<cfset var wayLongerName = "" />

public var name : String;
public var longerName : String;
public var wayLongerName : String;
</pre>

ah, fuggetaboutit

@Andrew
I knew what you meant. LOL. I've been known to do the same thing.

A while back I worked for a company who brought in a new DBA. New here means he was new to SQL 2005 but had seen 2000 and was more comfortable with DB2 and Oracle. His first official act was to add these rules and their reasons:

RULE: All SQL will be in lower case.
REASON: I simply don’t like mixed or upper case. Looks like shouting or yodeling.

RULE: All column names will be surrounded with [ ].
REASON: Some people like create tables with spaces or reserved words in the name best to be safe because I don’t know all the reserved words.

RULE: All table names will be fully qualified.
[ServerName].[database name].[user name].[table name].
REASON: We only have one database now but we could have more and we might connect to both in the same query some day.

RULE: Every sql statement will be free of tabs or carriage returns and written as one continuous line. Run them through the query editor in management studio.
REASON: Because formatting slows down code processing.

RULE: Any sql other than a simple select without joins will be rewritten as a stored procedure or view.
REASON: ColdFusion isn’t a Database and doesn’t understand these complexities.

RULE: Always use a UUID as the Primary key.
REASON: Even though Gender only contains male and female there could some day be more than that and we could wind up having more records than an INT can handle.

There were more but those I am certain of. The Employee to management relations degraded after that ad most of the coders left.

I’m all for standards. I like having FK_ in front of my foreign keys, and I like having _ID at the end of my Primary keys, but I don’t HAVE to have it that way. I like carriage returns and tabs, it makes reading easier, but I’m ok with using Dream Weaver’s code formatter too. Camel Case for the win!

"Even though Gender only contains male and female there could some day be more than that and we could wind up having more records than an INT can handle."

This is the most awesome comment on this thread yet.

I welcome our new genders!

Male
Female
Male and Female
Male from Female
Female from Male
Not Reported

@Richard
You left out:

Cloned Male
Cloned Female
Cloned Neuter
Cloned Male and Female
Cloned Male from Female
Cloned Neuter from Female
Cloned Female from Male
Cloned Neuter from Male

and I'm sure there's iterations that I missed (Just poking fun - but I agree - always leave room for "expansion/growth")

I got those from:
ISO/IEC 5218:2004: Codes for the representation of human sexes

There are standards for everything in government.

Those were his rules not mine, but yea we should leave room for expansion. But in this case I seriously doubt we run out of room with an INT hell even tinyint would do.

Wow, who knew.

ah - he is Canadian. I didn't think our government allowed for anything other than male or female.

Braces must be on their own line. :-)

Wrong:

private function myFunc():void {
// Code //
}

Right:
private function myFunc():void
{
// Code //
}

That goes for while, for, if, functions, etc. Unfortunately, I think I am a minority on this one.... ;-)

Yep - at least in my book you are Joshua.

@Joshua, +1 for the braces on their own line.

I'll go one step further. I don't care if you don't need braces because it's a one line condition, put 'em in. And the traumas I had with VB.NET (if I can speaketh of such things on this blog without the wrath of Raymond smiting me) and how the code was constructed, I thought tearing out my veins one by one with those little Swiss Army knife tweezers would be preferable.

Ok I do have a bit of a pet peve, all pages must pass:

http://validator.w3.org/
XHTML 1.0 Strict

http://jigsaw.w3.org/css-va...
CSS level 2.1

http://www.cynthiasays.com/
508 Compliance

:-)

I hate code that screams at me. I don't mind "compareNoCase" or "CompareNoCase" but I can't stand "SELECT" or "COMPARENOCASE". I don't care if all the stinkin' CF and SQL examples out there have it. With modern editors there's no need for it.

But really many of those things are about using a code beautifier instead of making developers change ever little habit until the next job. Let them do their thing as much as possible and have the beautifier take care of making the code consistant for future generations.

Allen:
Totally with you on this one. Whether it's sql, "constants", or scopes (application, session, variables), I absolutely REFUSE to use ALL CAPS. The only place I find it acceptable is in blog posts discussing how vile ALL CAPS are.

My one exception is mid-camelCase acronyms and "some" abbreviations.

<cfset userID />
<cfset nearNY />
<cfset lastIDCreated />

I'm right there with Adrian.

Here are a couple of regex's I have saved as snippets in Eclipse (CFE w/ shortcuts). I just drop them on the page and use them in the Find dialog.

Shortcut: fixcomments (makes sure 1 space at the start and end of comments) :-)
find: <!---(\S+)
replace: <!--- $1

find: (\S+)--->
replace: $1 --->

Shortcut: killnotcompare (changes "NOT CompareNoCase(...)" to EQ because I hate reading that)
find: (Not CompareNoCase\()([a-zA-Z\._]+)(,)(['"]{0,1}[a-zA-Z\._]+['"]{0,1})(\))
replace: $2 EQ $4

Those are the most used...

I'd call myself a code Nazi, not a code diva!

I look at all my code with hidden characters exposed, and literally get a brain meltdown if I see spaces instead of tabs or if someone used poor formatting of their code. I need my code looking a certain way. If it's not that way, it distracts me until I fix it.

For all the SQL (server) divas out there:
SQL Refactor re-writes it all for you....
http://www.red-gate.com/pro...

- Joel

@Brian: "I look at all my code with hidden characters exposed"

I don't even see the code. All I see is blonde, brunette, redhead.

Wait a minute, that's not CFML.

@Adrian,

Classic movie reference :) Good times.

> I always ask that people use "Raymond", not "Ray"

I just realized your email address is ray@camden...

@ps: Who said my rules had to make sense?