Skip to main content
Ben Nadel at CFinNC 2009 (Raleigh, North Carolina) with: Jason Dean
Ben Nadel at CFinNC 2009 (Raleigh, North Carolina) with: Jason Dean ( @JasonPDean )

ClearCode Standards Project

Published in Comments (71)

The ClearCode Standards Project is the development standard that outlines the way in which I code all of my applications. I have talked about my methodology before and since then, it has continued to evolve and become more refined. In this blog post, I intend to keep the most up-to-date outline of the rules and the styles involved. I have chosen to do this as a blog post rather than putting it in my ColdFusion section as I like the idea of this being an ongoing conversation in which I can both get feedback and respond to people's thoughts.

The Visual Science Behind The ClearCode Standards Project

Until now, I have only ever discussed my coding from an implementation standpoint; I have dropped little pieces of information as to why I do things the way I do them, but mostly, it has just been declarative, not explanatory. This morning, I was invited by Ayub Khan and Clark Valberg to present to both the Hyderabad and Chennai ColdFusion User Groups in India about my standard. I took this opportunity to really dive into the theory and the science behind why I code the way I do. Feel free to watch the recorded presentation below.


Ben Nadel Presents On The ClearCode Standards Project  

The ClearCode Standards Project

Below, I will be outlining the guidelines set forth by the ClearCode Standards Project ... coming soon....

Reader Comments


I enjoyed the presentation and I not only agree, but admire your initiative.

The style you suggest is configurable for XML using Oxygen (, provided you have Oxygen break attributes, which you can enable under preferences.

The formatting for XML (or in my case, MXML) is beyond description. The indentation and alignment are spot-on. The usability and consistency are excellent. Oxygen also orders your attributes alphabetically.

It would be wonderful if someone had a code beautifier for CF that had the formatting that Oxygen provides for XML, and that it adheres to the standards Ben proposes.

Note: I think your style suggestion applies more toward standard CFML than it does CFScript (which is fine with me).

Also, the standard color formatting for attributes, tags, and such isn't suggestive enough in any of the major IDEs. I'd like to see this initiative share colors formatting for the various iDEs to improve contrast and readability.



GREAT presentation. I really liked that you explained why code readability is so important.

I have one concern -- and it's just that, not something I've thought through very well. With each attribute on its own line, is it hard to get a sense of the overall structure of code? I tend to get lost with lots of lines of code. Or do you get used to this quickly?

Anyway, I thought you did a really fine job on the presentation. Very well thought out, structured, and delivered.



It's funny you mention that - I have actually had one or two people before ask me if there was some sort of script that I could run that would format a code file in the way that I program. I guess, I *could* write something that could get you sort of there, but I think it would take a long time :)


Really glad you enjoyed it. As far as your concern, I know what you are saying, but this is something you get used to real fast. I have never looked back from doing it this way and I never feel lost in my documents. Occasionally, I'll do the quick mouse-scroll just get my bearings; but, once I start to focus, I find the layout quite pleasing and efficient.


I really like the way you're applying these concepts to the "usability" of code and you present it really well and really convincingly. In practice I don't think I could ever bring myself to write every attribute of every tag on it's own line, but as John mentions perhaps a good IDE should provide a code formatting/viewing feature such as this for those developers that find it useful... However, I know that's not the main point of the presentation, and I think everything else is quite sound and I can see the benefits in helping raise awareness of writing code to a presentation standard. Nice work :)


Writing some kind of formatter would be time consuming. It's a dedicated project unto itself, and Adobe's recent IDE survey suggested that a future 'broom sweep' of code is possible.

Some argue that DW does have CF Formatting, but it's pretty terrible.

For productivity, a code beautifier would be invaluable.



There are exceptions to rule. For example, my CFQuery tag is never wrapped. I find that wrapping holds no value since the datasource, username, and password field add zero additional understanding. But, for the most part, I wrap everything. Once you get into the habit, there's really nothing to it.

But, yes, raising awareness of coding style I think is very important in the long run. Glad you enjoyed the presentation.


I'm loading the presentation right now, I'm stoked to check it out. I'm hoping some of what you got will rub off on to me.

Damn dude, you're a beast. That iPhone app got you swoled!


Heh, I've been meaning to write up something similar to this for ages, about my own structure/formatting methodology.

The whole readability/usability motivation I'm entirely in agreement with.

But when it comes to a some of your actual interpretations... well, I think you're crazy. :P

It's a good sort of crazy: you're trying to be logical and sensible - you're just not completely successful. ;)

Some of the significant things in your presentation which I disagree with:

1. Scrolling
For me, scrolling is important - why? Efficiency.
My editor window fits 120 characters across, but only 40 lines down.

Too many linebreaks is wasting both the width and height, and takes longer to read.

The area of focus isn't relevant - eyes move far quicker than scrolling

Not making effective use of the screen slows down readability and makes it harder to reference surrounding code.

Pointless comments are a huge waste of time - again it just slows things down (both reading & writing).
Code blocks can (and should) be seperated with newlines - real whitespace, not grey comments.

I forget the exact wording, so hopefully I'm mis-remembering, but you mentioned something about being able to ignore comments - this is completely wrong.
Comments should be placed to explain things that are not obvious, and should never be ignored.

3. Commas
Something annoyingly ignored is commas. It's not just you - everyone seems to do it.
They're very important to readability, and yet everyone just treats them as if they're writing English language rather than code.


Don't do x[comma][space]y:
Function( arg1,arg2,arg3 ) = not great
Function( arg1, arg2, arg3 ) = BAD
Function( arg1 , arg2 , arg3 ) = GOOD

This bugs me - it's not readable:
SELECT something,
another_thing AS whatever,
and_this AS that

But with commas at the front, it helps readability
SELECT something
, something_else
, another_thing AS whatever
, and_this AS that

And it removes the whole "crap I added an extra column but forgot the comma" situation.

Anyway, as I said, good that you've at least got a structure, even though I don't agree with lots of it. :)


+1 for having Charlie add this to his site - and consider doing this as a CFMeetup!!!!!!!!!!

Some good stuff here - but this is such a personal thing I think it's difficult to say "this is best". I used to like wrapping stuff but since I've begun using a widescreen monitor - I don't mind long lines of code as much.

But for things I read or change frequently - CSS, comments, body content - I do keep those wrapped. Stuff I write once and rarely change - I leave those unwrapped.

I do break up my scripts similar to you - but I tend to follow my SQL formatting and put AND/OR, commas, etc at the beginning of lines instead of at the end. I gotta have commas first :)

Looking forward to the cliff notes version!


YEAH BEN!!!! Great stuff. I have been formatting my code very much like you for a few years now but it's helpful th have something concrete to work from so you don't get lazy and make exceptions (i.e. sometimes I do scope variable in all upper case and sometimes just the first letter). I have read some blog posts that some people find your coding style HARDER to follow but I think that's because of the way they think, and they can easily be re-trained. I would be interested in hearing what your thoughts are on tab size because I set my editors for 2-space tabs because 4-space tabs seem to create too much horizontal line width (especially with multi-level hierarchies) and it seems to leave islands for very short tags or attributes.


Stick to your guns Ben, your visual orientation is right on and the parallel with print and web publishing is also right on. Other people are free to do whatever they want and have their own opinions but they would have to come up with much better arguments that Peter has to convince me.


David Buhler mentions having the tag/function attributes in alphabetical order. I saw Dreamweaver 8 do this before I switched to CFEclipse and I carried it over. I found that if the attributes are always in alphabetical order it's easier to find "missing" or misspelled attributes.


It's good to have a standard. There is room for more than one standard. for instance, I don't like commas first, some people do. fine. no problem. I don't think anybody is saying there is only one way to code. Ben has a standard I happen to like so I might change my style to meet his standard. For instance I never put the /> on a separate line before but when I started putting attributes in alphabetical order (perhaps too anal for some people) it meant moving or adding attributes to the end was easier.


as far as monitors go, it may be difficult to standardize on a physical programming environment but everyone has to have at least a 17" monitor right? A 17" flat screen probably has the clearest picture at 1280x1024 for a standard width... maybe a little less for a widescreen. I have a 20" monitor that I run at 1600 x 1200 and I get 16 lines and 130 columns on it.

Yes you eyes move faster than scrolling but Ben's point is the the eye has more difficulty scanning to the end of a long line then returning the the start of the next line than if you had a short line of code.


(any chance of compiling your comments into a single post in future?)

>> but everyone has to have at least a 17" monitor right?
Not necessarily, but I feel sorry for anyone who doesn't. :)

At work I've got 2x17" at 1024x768 (crappy old graphics card)
At home my main screen is a wide 17" at 1440x900 (plus a secondary 19" at 1152x864).

The 120x40 characters is at home in CFEclipse with other panels - with a full-screen notepad-like editor, I get 200x65.
But anyway the point is that whatever configuration there is much more width than height.

A cffunction with six cfarguments taking forty or more lines, rather than just seven, is a waste of space and not beneficial to readability - I can't quickly see all names or types.

As you can see - there is no scanning to ends of lines required here, and I can much more easily read the important bits of code.

I am explicitly talking about cffunction/cfargument here by the way - some tags do benefit from being across multiple lines, as do certain function calls.
Thinking a little about which ones, I think anything that has a name/value pair type of structure is something I do multiline.


I also find myself coding differently for different things.

CF - I like everything tight except for the occasional cfscript.

CSS - I like everything on it's own line, alphabetized.

jQuery - I like lots of lines and indented code.

SQL - I like stuff tabbed so it lines up vertically, and everything on it's own line.


Hi Ben,

Thanks for the great presentation to India CFUG (Hyderabad and Chennai ColdFusion User Groups). It will really helpful for the fellow developers here to practice better coding standards in ColdFusion. We are looking forward for your more guidelines on ClearCode Standards Project.

- Akbar


What's great about this is idea is that people are talking and thinking about how and why we need to write readable code. I tried rewriting some of my own code for comparison (I posted the results here:

It is important to have coding standards (even if it is just for in-house use) - this is one of the reason that I like frameworks, so that if your team changes or grows then a new team member should be able to pick up any of your projects without the added headache of learning the coding style as well.

What I'd really like is a way to stop designers opening my code and messing up the formatting :)



My screen fits 50 lines of code :P

But honestly, I have never felt the need to scroll very much, or if I do scroll, I have never felt that it slows me down. Usually, I scroll to find a point in the code that I need to examine, for example, a specific function that is throwing an error or returning an unexpected value. In that case, I can quickly scroll to it or, if it is a rather large file, do a CTRL+F to quickly jump to that function name (or in something like CFEclipse, select the document outline item). Once, I am there, my scrolling is very minimal - I am picking my way through the code looking for the point of error.

So for me, scrolling is not point of concern. It is not part of the primary gesture of my editing.

As far as comments go, why would you say comments should never be ignored? If you go to edit a document you just wrote, do you always read your comments? If I am very familiar with a document, chances are, I will ignore all of the comments, or if not, make extremely hasty split second reading of them. From a meaning standpoint, comments only help me to understand a document better when I am not familiar with it. Now, that may be in 3 days, 3 weeks, 3 years, or it may be for code that I never wrote originally. To me, the comments provide different uses at different times depending on the context in which the document is being read.

I do like your comma idea. With the space on both side of the comma, my eye does have a slightly easier time jumping from argument to argument. However, I am also enjoying this same jump with the arguments on different lines.

As far as the commas at the beginning of lines of a SQL statement, I don't feel that this adds much value. The new line is already creating a visual anchor, I don't think the commas creates a stronger one. And, the whole, "now I don't forget my commas", I think you are finding a solution to a problem that shouldn't be a problem. Meaning, how often do you actually forget to add a comma at the end of each line of the SELECT statement? I would guess that this is very rare. I don't think that something like that should dictate a change in coding style - commas should just be added by habit.

Also, what happens if you have more than just a SELECT in your statement? Say, something like this (taking your example):

. . . , something_else
. . . , another_thing AS whatever
. . . , and_this AS that

(I use dots for tabbing since PRE is not supported yet). Now, you have a huge visual misalignment of columns. I would recommend wrapping the first line as it takes away the dynamics of the SELECT:

. . . . something
. . . , something_else
. . . , another_thing AS whatever
. . . , and_this AS that

I am also very curious about the CFargument tag formatting color code that you demonstrated. For starters, you tab out your argument attributes to create visual alignment. I like this a lot. I feel that this is very similar in spirit to what I am doing with new lines - you are using white space to create proximity and organization - same goal, different means. But the highlighting that is in place - did you add that? Or did the light blue-gray automatically extend past the quotes of the argument?


In my CSS, I list all of my properties in alphabetical order since none of them is technically more important than any other (can you really say that text-decoration means more that color of font-size?).

However, in my tags, I like to put the most meaning full tag attributes first or in such a way that they tell a story. Take the CFHttp tag, I think to myself, "I am calling this url with this method and I want to store it in this value". As such, the attributes usually follow that same story line: URL, Method, Result.



I find the 4-space tab to be very pleasing. 2 spaces to me doesn't feel like quite enough separation of columns. 8 spaces feels like waaay to many.


More important than any one given standard, I think it is just important for people to actively think about the code that they write. By thinking about it, I can guarantee that it will become better code.


> As far as comments go, why would you say comments should
> never be ignored? If you go to edit a document you just wrote,
> do you always read your comments?

It's not a case of reading vs not reading.
If I'm familiar with a document, I read neither comments nor code (I'll scan function names / similar and jump to the relevant part).
If I'm not familiar it, I'll read both.

ie: Comments form an extra piece of syntax to help code make sense, and I don't ignore them in the same way I don't ignore <cfparam.../> blocks - but I will skip such blocks when they're not relevant to what I'm looking for.


> how often do you actually forget to add a comma at the
> end of each line of the SELECT statement

It's not something I do at the end of each line - it's when I'm adding extra columns on, maybe c&p from another query. A trailing comma is easy to forget about, until you get odd errors about missing/incorrect vars.
Also, I don't see them as different to logical operators or concatenation, eg:
<cfif Something
AND Something
AND Something

<cfset Bob = "This"
& "That"
& "So on"

> what happens if you have more than just a SELECT

I generally don't.
If I'm hitting a database directly I might, but in permanent queries I don't tend to have a need to limit the number of rows.
For DISTINCT... I think a DBA once told me if you're using DISTINCT your joins are broken. (something along those lines).
Again, useful when doing quick queries directly, but not too common in actual code.
I think I have examples of both though, and I've either shifted things along further or wrapped the first line. Possibly both in different situations.


> For starters, you tab out your argument attributes to create visual alignment.

I space them out, not tab.
Tabs are for indenting only - any mid-line whitespace *must* be spaces or it wont line up with different tab stops.

> But the highlighting that is in place - did you add that? Or did the light
> blue-gray automatically extend past the quotes of the argument?

Sorry, should have said - I added that to help indicate how my brain sees it - I mentally see the column but there is no actual colouring in the editor.
(Although it is the type of feature which an ideal editor should be capable of)

> I feel that this is very similar in spirit to what I am doing with
> new lines - you are using white space to create proximity and
> organization - same goal, different means.

Indeed. We are definitely both attacking the same problem, despite the quite different final styles.



"For DISTINCT... I think a DBA once told me if you're using DISTINCT your joins are broken."

Well played :) I actually agree with that like 99.9% of the time. It is very rare that I need to use DISTINCT.

I think clearly, we both think very much about the style in which we code and have very well grounded reasons as to why we do what we do. Like I was saying to John, I think this is the this is more important than any given standard. While our implementations are different, we both see the value of visual flags to make better "interfaces" out of our code.


Great presentation. I only had time to skim through it but loved what I saw!


+1 to Peter Boughton. I was going to say the same thing about treating logical operators like commas and putting them at the beginning of a line.


You may have covered this, but I've started paying more attention recently to how code formatting affects source control. Code formatted the way you describe makes beautiful diffs.


Scrolling is not so much of a problem if you can orient your monitor vertically. Just try it. It rocks. :)


You need triple monitors. 1x in horizontal widescreen and 2x in vertical widescreen.

1050x1680 resolution is perfect.



Ha ha ha :) I have two monitors, but the only thing I put on my second one is my music player. Granted, my one monitor is large (I get about 50 lines of code on it), but really, its more than sufficient for my style of programming.


one thing I like about putting attributes in alphabetical order is that is works for everything: functions, arguments, select statements, so it's really easy to say to someone... just put everything in alphabetical order, you don't have to think and rethink (and then memorize) which attributes are "more important" and have someone else say "well I thought Type was more important than Name" or some other crap.

it might even make you think a little more carefully about your naming conventions.


Holy shiz Ben. You just saved me having to buy Christmas presents for a bunch of my friends. I'm forwarding your presentation to them instead.

For the record, you're dead on with the scrolling argument. I'm about 100% sure that research would back your theories up to the bank. There's no way you can read an 800 character-long line of code nearly as fast as you can read 8 100 character-long lines of code, scrolling involved or not. Just because your monitor can accommodate enormous widths of text doesn't mean it's physiologically easier for you to read them.

Ideally, IDEs would let you zoom in and out on code like you can in graphics editors, allowing you to zoom out for a broader, more explicit and descriptive overview of the literal organization and play of code than is possible with tools like CFEclipse's outline view, but until then, PAGE UP / PAGE DOWN and/or a scroll wheel are more than ample.

I'm going to try your techniques out for a month and report back on how much weight I lose.

I actually agree with 100% of your tactics except 1- the upper-casing of scopes and SQL. Oh, and that you prefer Homesite to Dreamweaver. Other than that though, damn son.



I am not so sure about alphabetizing attributes. I like the idea of important attributes being first. Think about the CFQuery tag. While we have connection information in the attributes, is there really anything important other than the Name attribute? Do we even need to understand what is in the other attributes? I would argue, No.


Glad you liked it so much :)


so then you would say put the name first and alphabetize the rest? I could probably accept that, it would be an exception though and the fewer exceptions to the rule the better.



I will have think this one over. On the one hand, I do put all of my CSS rule properties in alphabetical order. But, I feel that none of those have importance or weight to them - there's not story being told.

Tag attributes, on the other hand, just feel to me as though they have a story - a path of processing.

Plus, I am not sure that alphabetical order requires less thinking. In fact, it might require more; you probably aren't thinking IN alphabetical order when you write your tag attributes, so that as you add more attributes, you are going to have to adjust your cursor to have a new insertion position.

I will think more about this, but my gut says that alphabetizing actually requires more thought and effort.


Dumb question: Why does the order of attributes / named arguments / CSS properties need to be stable? What does it matter if one cfquery has name first and another has datasource first?



For starters, Named attributes should be stable because they can *also* be called as ordered arguments (assuming your function requires them to be named due to a large of amount of argument combinations).

For CSS, I just love seeing them in alpha-order. Because CSS can often times have many properties per rule, and including a rule twice doesn't cause exceptions to be thrown, and the highly cascading nature of CSS - I like that it can be seen in a single, given order. I like knowing that if my first property is "color", I know that "border" is not being defined at all. The order gives a lot of meta information about the rule.

For tag attributes, stability is important for fast scanning. If you always except the Name attribute of a CFQuery tag to be first, you never have to think about it - its the only important tag attribute (really) and it's front and center. If you hit a CFQuery tag that doesn't have it first (when so many do), now you have to stop and think.

It'd be like occassionally switching STOP signs on the road with HALT signs. Sure, they both mean stop, but one is breaking an established paradigm which causes you to have to stop and think and interpret.


Ben, so do you alphabetize all of your CSS rules independently of their type in a singular list?

I usually separate HTML overrides(h1, div, td), id-based selectors (#divHotLadies, #tableLoginForm), and classes (.averageLookingLadies, .highlight) into three comment-segregated groups and then alphabetize them within that. Where the benefits of that really come into play is troubleshooting and debugging when you're knee-deep in cascade. As you work though all of the styling applied to a particular element that's having a weird effect that you can't figure out (usually browser-compatibility), it's helpful to be able to start from the outside in, and work up the style hierarchy.



Sorry, I was not very clear on what I mean, and part of the problem is that I don't know all the exact terminology.

When it comes to CSS rules (ex. H1 or p#help), I put those into three different sections based on types of context. But as far as a SINGLE rule goes (ex. div.note), I put the individual properties in alpha order:

div.note {
. . . . color: black ;
. . . . font-size: 10px ;
. . . . text-align: justify ;
. . . . width: 80% ;
. . . . }

Notice that color, font-size, text-align, and width are all in alpha order. That is the only part of the CSS that I was talking about.


Ah, gotcha. I've never tried that before, my attributes usually follow a natural hierarchy of visual implication.

Meaning positioning, layout, height, width, things that are potent enough that they could affect other elements come first.

Then sub-"positioning" styles like margins and padding and borders.

Then purely 'stylistic' styles, like colors and font-effects.

But really, there are usually so few styles applied to any given selector that alphabetization probably makes more sense (probably). I guess my attribute ordering just models my development process, and that seemed to stick.



I think the key here, as I have stated to other people, is just to be conscious of the code. You have a standard that you follow - that's what is important. Your way or may - at least you are not just adding CSS properties as you think of them, all willy nilly.


I see your point, but at the same time I think that there is usually an absolute, unarguable best way to do most things, and I want to get to that point as soon as humanly possible in all of my professional endeavors and never look back.

Macho Man Randy Savage and Indiana Jones spent their entire lives pursuing that mentality, and I'm no different. And that's why your presentation was so exciting. The end.


One more thing. I felt like you really had something when talking about how commenting should tell a story, and when working with unfamiliar data (especially your own), that story should be easier to digest than the same-but-different story that your code itself tells, because you can read comments (English) better than you can read code (Portuguese), even if you are fluent in Portuguese. It was still your 2nd language.

I totally take the same approach, and a lot of the time I'll actually write out a comment narrative of everything I want to happen on a page before I start coding at all. I use list-type delimiting to reinforce structure, and as I go from item to item I have sub-stories of comments that describe each larger group.

Hopefully that made sense. For example, before I start coding I'll write:

!--- 1. Make sure an idItem was passed into the page ---
!--- 2. Retrieve data for the specified item ---
!--- 3. Display the item data to the user with editing controls ---

Then, as I go through and code the 3 sections, between 2. and 3. for example I'll have

!--- To users, items and itemPrices are a singular concept, retrieve all of the item's prices and return them with the item data ---

!--- Each item belongs to one category, retrieve and merge the category into the item record ---

And so on and so forth.

Where this really gets interesting is with varying-colored comments. With the current IDEs, the only way I've found to do that is by using multi-language comments together, usually HTML and ColdFusion.

Take a look at this screenshot.

Granted, there are side-effects. The document you send to users will have your HTML comments (unless you strip them out, which if you have a highly-capable, under-utilized server, DO IT. Along with all whitespace.

One last note. You mentioned that various techniques you use server the purpose of helping you VISUALLY SCAN through the code and consume its message or story more rapidly. That's what the standout gold comment background does for me. I put my major action summaries in bold gold, and the details and walkthroughs in a more neutral, less eye-stopping color, but one that still lets you visually treat them as related. Have you ever tried it? Solid-background colored commenting? It's one of the primary reasons I don't use Eclipse more. And one of the primary reasons commenting is fun, because it looks pretty.


Note: Ignore that actual code and comments. They don't make sense as-are. Just look at the structure, concept, and coloring.

That screenshot is from a long time ago and I was clearly OD'd on sugar at the time.



The different colored comments is a very interesting ideas. Like Headers and SubHeaders in a paper. I would have never thought of adding something like that. I wonder what kind of tweaking can be done in my IDE to that effect.

What you said made sense and good screenshot.



Looking at your div.note {...} rule, my eyes tend to focus on the values before the properties. Values are more visually distinct than properties (especially within an editor that gives different types of values different colors).

Also, looking at the CSS for this site, the vast majority of your rule sets have five or fewer property names. And the longer ones tend to be mostly "font-*: {default value}." I doubt that alphabetizing has as much impact as you think.




I tend to agree with you. It doesn't make a huge difference. Where I feel this most is when I trying to debug someone else's code and their properties are all over the place. I most definitely feel the impact of having to find their rules PLUS be thinking at the same time as to why code isn't working.

Sure, maybe I am just an unfrozen caveman programmer that was frozen in ice and then thawed out by your scientists, but I know that when I am debugging, I want to cut out as much thinking overhead as possible.

So, minor? Absolutely. But noticeable? Definitely.



I believe most code editors do this by default. However, you should be able to set this in the editor settings.



Really??? That seems a bit bananas.

As you all know I am HomeSite fanatic and it is pretty awesome. You can completely edit entire language schemes including foreground, background, bold, italic, and underline. The font size and family are controlled by the overall editor, not any given scheme. I do love my HomeSite :)


Yes - just something Mark hasn't got to (yet). I know it can be done because Aptana has decent controls - color, bold, italic, etc over each of it's editors - CSS, HTML, etc.



Oh, I didn't realize it was "type" specific. I figured that was just a feature of the Eclipse platform in general. I know, "type" is not the right word, but I can't remember what term is used for the "personas" (ex. Java, CFEcplise, etc.).


Hi Ben,

As you all know I am HomeSite fanatic and it is pretty awesome. You can completely edit entire language schemes including foreground, background, bold, italic, and underline. The font size and family are controlled by the overall editor, not any given scheme. I do love my HomeSite :)

I couldn't agree with you more, especially the built-in reg-ex for extended search-and-replace ;-)


Hi Ben,

I did your methodology on a recent flex project and then attempted to do the same thing with CFEclipse on a ColdFusion project.

It was like night and day for readability for me. Thanks for showing me the light. It also encouraged me to learn a few more keyboard shortcuts for eclipse.

Unfortunately, your methodology is impossible with CFEclipse as you know. Given that Flex builder does it well, it is native to CFEclipse and can be fixed! I'm actually going to regress and try homesite+.

If adobe puts the effort in to the CF IDE for eclipse as they did for Flex Builder, I predict an immediate takeover of the entire industry for ColdFusion. Each and every PHP and ASP website will immediately convert to CF.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel