Firstly, hey thanks to everyone who filled the survey in! I got over 100 responses within the space of a coupla days. That's the fastest I've had responses to a survey. Cheers!
Anyway, what did you have to say?
Q1: Which CFML server do you primarily use
| Answer Choices | Responses |
|---|---|
| ColdFusion 8.x or lower | 2 |
| ColdFusion 9.x | 23 |
| ColdFusion 10.x | 37 |
| ColdFusion 11.x | 5 |
| Railo 3.x or lower | 0 |
| Railo 4.x | 33 |
| Other (eg: some flavour of BlueDragon) | 0 |
| Total | 100 |
It's interesting to see how little traction ColdFusion 11 has, and that Railo 4 has almost as much popularity as ColdFusion 10!
Ooh... because I have only a freebie account with Survey Monkey, I am not able to see the last five results people offered. I'm so sorry about that (ie: you put the effort into responding, but I can't use your answers). So I can only report on the first 100 responses. I was closely monitoring the response count, but the last five responses came in during the time it took for me to see there were 100, and for me to switch the survey off. Dammit.
Q2: which of the following example function signatures would you tend to use most often?
(a) fully-qualified script syntax:
public numeric function getValuesOverThreshold(required array data, numeric threshold=0){
// implementation
}(b) minimal script syntax:
function getValuesOverThreshold(array, threshold=0){
// implementation
}(c) fully-qualified tag syntax:
<cffunction name="getValuesOverThreshold" returntype="numeric" access="public" output="false">
<cfargument name="data" type="array" required="true">
<cfargument name="threshold" type="numeric" required="false" default="0">
<!--- implementation --->
</cffunction>(d) minimal tag syntax:
<cffunction name="getValuesOverThreshold">
<cfargument name="data">
<cfargument name="threshold">
<!--- implementation --->
</cffunction>| Answer Choices | Responses |
|---|---|
| (a) fully-qualified script syntax | 55 |
| (b) minimal script syntax | 10 |
| (c) fully-qualified tag syntax | 27 |
| (d) minimal tag syntax | 3 |
| (e) Other | 5 |
| Total | 100 |
The "Other" votes were as follows:
Legacy code, pre Railo, pre FW/1 (so we're talking Fusebox) -> (c) New code, Railo, Mura, FW/1 -> (a)
function WhereValuesOver(arg){ arg.array arg.threshold }
Mixture between minimal and full cfscript syntax
I would probably tend more towards "a" 60%-70% of the time, and "b" after that (assuming I am working in a script based part of the system, roughly same percentages would apply to "c" and "d" in a tag based part of the system). I would use "a" where I care about having validation built into the function definition. But there are times were honestly I just don't care about that so will go with the minimal approach.
I tend to use fully qualified syntax. Primarily script, but as the discussions lately have made clear, script doesn't cut it for everything in CFML, even now, so I use fully qualified tag syntax when I must use tag based code.
Two things surprise me here: how many people use CFScript over tags. This is brilliant.
The other thing is how many people go for the fully-qualified approach.
Personally, I'm split here. If I was writing an API for others to consume... not others in my team, but other client users... then I'd take the fully-qualified route.
However increasingly with my own internal code I'm just writing the shortest code possible. Also if bearing "Clean Code" in mind, I think a lot of type information and requiredness can probably be inferred from clearly-written code?
On the other hand, I would much rather a function call die because I was passing a string when it needed a Name object, rather than the code within the function die when it comes to use the Name object. I'm undecided here.
In my script function definitions I have stopped specifying when things are strings, or if it's very clear the one argument to the function is clearly required (like on a setter). And for my blog sample code I pare the code back as much as possible to simply demonstrate the point (which is seldom that the argument is required and is a date, for example).
Q3: do you tend to write your processing logic code (as opposed to your view templates) in script or tags?
Script: 75
Tags: 25
(I don't think there was any need for a table there ;-)
There were a fair few comments on this one:
I tend to write everything in tags, mostly for readability, and perhaps a little bit because it feels different than other coding languages I use (= keeping it fun (tags are my guilty pleasure)). I find it also helps keep our team in line. Allowing everyone in a larger team, all with different ways of working, to write in script just results in clutter and unorganized structure. I think it's better not to depend on team member's discipline and will to code like one person and just use these tags, that allow little or no differences in manner of writing.Weird how people equate "tags" to "readability". I find tags awful to read compared to script. I'm not suggesting the commenter is wrong - it's entirely subjective - but I find it odd.
I have converted to writing all code except presentation layer in CFScript. Presentation layer still uses CFML. Of course, I also still have to support old code that was written in CFML.CFScript is part of CFML. But yeah, I get you mean "tags". I'm the same, FWIW. Tags are cool for views.
Except when using CFQUERY or CFMAIL (maybe more) since these are more straight forward as tags.I actually find
queryExecute() pretty easy to use. I don't write many queries though (we're a proc shop).Even with query execute making things nicer, I still break queries out into tag syntax. Same for savecontent if it's complex enough to make the script version look hairy.Yeah,
<cfsavecontent> is def better than how savecontent(){} is implemented / needs to work.Fair to say I'm about 50/50 on maintaining older tag based apps vs new apps in script but moving to script wherever possibleThat's what I like to hear!
I grew up on tags. Most of the old code is in tags. Working on learning script.
I am just starting to transition to script code for processing/business logic, but its not as fast as I would like. We recently brought on a new developer that uses script syntax so that has helped push me in that direction.
I deal with a lot of mixed cases - situations where there is too much legacy code in tags to effectively re-write it in the available time frame. For those situations, I'll tend to drop into cfscript where possible.
I'm moving towards using more script.
Script for new components / migrating old code to script.
I normally obfuscate them into CFCs I tend to migrate new code that has no need for tags into script based code, but sometimes it is much easier to read and utilize tag based code - cfquery is a lot prettier overall then both of the query syntax even though reusable parammerterized queries can be powerful. I wish in a script based cfc there was a way to do the opposite of to turn cfml parsing on for a short section.
Tags suck big green donkey dick. :-)I think they have their place. Not for functions though.
New code is script based. The legacy system I support is approaching 15 years in age so some parts have just not been ported over to a script format yet, so sometimes it is back to tags.
In CF9 I would never use script as the quirks and missing functions annoyed me, but in CF10 script is much better than tags for logic codeI do mostly CF9 (my day job is CF9... when it's not PHP), and I really don't find that much that I need to swap back to tags for.
99% of the site I work in is tag based, and frankly that is still where I have the widest margin of comfort.Good on ya for yer honesty.
Limited support for scripts led me to do tag based cfc out of habit and use cfscript with an easy way out if something isn't fully supported / weird. //implementation, if I hit a snag I can break out of cfscript and get back to it.
Where I can, I am writing more new code in (and migrating more old code to) the script syntax. The one exception to that is queries: in CF10, the syntax for queries using cfquery is so much cleaner and simpler than the horrible component-based mess provided by Adobe for queries that I just can't go there.
Per above, certain things are just not as easy to do in script as in tags, even now. I still much prefer tag syntax to anything else, and certain tags are difficult to deal with in script, cfldap being one where I struggled to even find adequate documentation on the script version of the tag and where it seems infinitely easier to get the syntax right in tags.
Script in almost all cases. Unless it's in view helpers, then it depends on whether using CFSaveContent a lot won't lead to cleaner code.
CF9 tag support is not amazing and i am still not convinced by CF11 tag support + its a legacy site using 100% tags and converting to script is not my biggest priority. TBH though i have not tested CF11 tag syntax yet (only read, hopefully updating soon so i may have a go then).
I mostly work on applications those are designed in 2002/2003 , so they all are tag based. So my client suggests to follow that only for consistency. But personally I like to code in script based syntax.
Obviously it's not possible to code *all* logic in CF9's CFML dialect, but if possible (like if I was using Railo 4.x or CF11), I'd write all logic entirely in script.
What I find best here is how many people are actively shifting to script-based code. Excellent stuff.
Q4: Anything else to add?
There's lots of older code I deal with that has minimal tag syntax
added hint attribute for function/arguments usually code running not only on cf10 but cf9+/railo3/4
the less data typing you write, the easier transistion to Node.js from ColdFusion
cfquery and cfsavecontent... if they could just make those two behave well enough in script I'd rarely ever drop into a (non-custom) tag again.
My blank template is:Yep. That sure is blank.
cfquery is still the bomb, therefore DAO is still written in CFML. Even executeQuery() is no match (and seems like it has thread safe issue pointed out by http://www.raymondcamden.com/2014/10/9/Another-bug-with-queryExecute--Threads
Tacos!
YO! Cameron! WTF?! Hope to see you again at dev.Objective() 2015.Thinking about it? Presume this was Mr Quackenbush?
I like puppies.Never tried them.
I normally do option a, although I rarely define the return type.
Id say im a cross between the minimal and fully qualified script - I dont include parts that are the default (public, any), but I do still use required and types where appropriate.
It's amazing(ly infuriating) how much is still either missing or unnecessarily complex in script.
You smell greatIt's true.
Occasionally I have to break out of script as I've found certain functionality just doesn't work - particularly the cfcookie tag for some reason in CF10. But then I just do a tag based function and call it as a UDF in the actual script block, so at least the logic is separated out.
Using fully qualified script/tag base syntax is always the better as it makes your code more readable and robust. I tend not to use hint though and use a comment if i really need to explain an argument - it just seems wrong putting code comments within a tag.
I also, out of habit, nearly always add the output=false to the function, so: public boolean function myFunction( required array myArray, boolean doubleCheck=false ) output=false { // ... }
When I was a child I used tags, now I'm a man I use script ;-)
I find tag based signatures much more readable and they provide a good separation between the function code written in script.
Generally prefer script, but find tag based queries more convient than the script equivalent. I often write my "DAO" layer as tag based, and services / controllers in script.
I don't have a great deal to add there. I'm just pleased someone noticed I smell good.
Anyway, I got a plane to catch, so am gonna sign off. Thanks for the answers, it was a good insight into how people are writing their CFML. Obviously this is only a cross-section of social-media-participating keen CFML community people, so is not necessarily representative of the great unwashed (who don't smell as good as me).
I was asking because I was thinking of writing some more CFML documentation, and wanted to know where to pitch it. Obviously the docs won't be aimed at you lot, but I won't be a complete loony if I just use script and completely ignore tags for this sort of thing.
Cheers.
--
Adam
