wtg/public/coding_standards/style.html

SeanCorfield — 2006-04-14T15:28:05

Wadem, a very fair point. I shall make sure the next revision of this page does show cfqueryparam.

wtg/public/coding_standards/style.html

Wadem — 2006-04-12T01:52:48

SeanCorfield that was a very easy point to make... there are no variable's so cfqueryparam is not required. That point taken do you not think it would be a good idea to add at least one example in the same section, that uses a param. So that if a complete CF novice was reading this page they would see right away `

wtg/public/coding_standards/style.html

SeanCorfield — 2006-02-24T09:33:13

Matt, if the SQL examples used variables, cfqueryparam would definitely be present.

wtg/public/coding_standards/style.html

MattRobertson — 2005-07-27T14:10:03

Why isn't cfqueryparam shown in the SQL examples in the MX coding Guidelines? You would think something so critical would be illustrated so that beginners and even intermediate developers would begin to be aware of its existence.

wtg/public/coding_standards/style.html

SeanCorfield — 2005-03-05T13:16:16

The SQL coding guidelines come from our Oracle DBA team.

We like the upper case SQL code because it makes it stand out on the page, distinct from the CFML that surrounds it.

Also, some databases are case sensitive so using all upper case table / column names is actually safer (more portable). However, the most important thing is consistency. As it says on the opening page of these guidelines, you are free to take the document and change it for your own use.

wtg/public/coding_standards/style.html

nathany — 2005-03-05T10:47:22

Really good read... a very nice set of standards so far.
The only thing I would change, is the yucky all upper-case SQL
statements. Why is that? Shouldn't database field names should be
consistent with variables names used the rest of the application
(headlessCamelCase)?

The following example is never going to come through nice on the
forum. So I'll try
to describe it. The tabs form a nice solid line between the statements on
the left and what data they are working with (all expect for order by,
which is a tad too long and I'd rather not add another tab just for it).
Keywords like on/and have a tab before and after, so they are separate
from the main keywords. Keeping the "and" at the beginning of the same
line as the expression makes it easy to comment out that one "and"
when testing things.

select to1.columnOne, to1.columnThree,
tt1.columnTwo
from table_one to1
join table_two tt1
on to1.tableOneId = tt1.tableTwoId
where tt1.tableTwoId = cfsqltype="CF_SQL_INTEGER" value="10" />
and to1.columnOne = cfsqltype="CF_SQL_VARCHAR" maxlength="40" value="AndIndented" /
>
order by to1.tableOneOrderKey

wtg/public/coding_standards/style.html

eric.moritz — 2004-12-27T07:40:04

You can also add xml complience by simulated a cfif with a cfswitch like the xslt choose tag, although it is hard to simulate some cfelseif's without some clever coding.:

i = 10;

Yes, #i# is greater than 3

This is the else equivilent

wtg/public/coding_standards/style.html

SeanCorfield — 2004-07-22T10:14:21

The non-compliance of code generated by CFFORM is a known issue that will be addressed in a future release.

wtg/public/coding_standards/style.html

JButter — 2004-07-22T05:57:24

Concerning the HTML & XHTML Compliance section: Some ColdFusion tags force non-compliance to this standard. Use of CFFORM in conjunction with any CFFORM control creates ugly, uppercase, non-terminated form controls. The only choices you have is to not write XHTML or not use CFFORM.

This should be addressed in a bug fix or new version of CF anyways. Otherwise, why even provide the CFFORM tag at all.

wtg/public/coding_standards/style.html

SeanCorfield — 2004-04-13T11:03:28

Yes, by the time the page reaches the browser, the ColdFusion tags have been processed and are no longer part of the document.
This guideline is merely about visual consistency within a source page: rather than have some tags be closed XHTML-style and some tags not, it is easier on the eye - and more consistent - to close all tags XHTML-style, regardless of whether they are HTML or ColdFusion.
Furthermore, if you get into the habit of closing all tags XHTML-style, you are more likely to write XHTML-compliant HTML.
The same logic is what drives the recommendation to have lowercase ColdFusion tags (to match lowercase HTML tags, required by XHTML). The lowercase tags do not contribute to XHTML-compliance but they provide a most consistent visual style and, in my opinion, make code easier to read.

wtg/public/coding_standards/style.html

ednagel — 2004-04-13T04:36:01

It may just be me, but isn't ColdFusion script processed out of the page before being sent to the Web server and subsequently, the client's browser? And if that is the case, why would you have to make your ColdFusion code XHTML compliant? After all, once the CF server processes out the CF code, if applicable, it will be replaced by html and the CF code won't be there anymore! I would appreciate any understanding you would be willing to pass along.

LiveDocs Comments - wtg - public - coding_standards - style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html

wtg/public/coding_standards/style.html