Since the linter fails for non-scoped, non-local variables (see: #17 ), there should be a "global" directive (similar to jshint) which allows you to specify which variables exist in the global namespace. This would be a linter option and an option in comments at the top of a file // global: varNameHere

I don't think that this should apply to CFCs (since having to declare all the CFCs within the "global" directive would get annoying pretty fast). So basically, if new is being used, the linter won't fail. Example pass: var x = new X().

(note: both "global" and "globals" keywords should work to reduce pointless frustration)

Use of evaluate() should fail lint.

The linter should require a return statement (with a variable or constant) for functions with return types other than void. If a void return-type function has a return statement (with a variable or constant), it should not pass lint.

Sample passes:

function numeric numFunc() {
   return 1;
}

function numeric numFunc() {
   var x = 1;
   return x;
}

function void voidFunc() {

}

function void voidFunc2() {
   return;
}

Sample fails:

function numeric numFunc() {

}

function numeric numFunc2() {
   return;
}

function void voidFunc() {
   return 1;
}

function void voidFunc2() {
   var x = 1;
   return x;
}

Instead of alternating between do-notation and bracket-notation to access static struct keys and variable struct keys, respectively, always use bracket-notation:

YES: myStruct['item1'][var1]
NO: myStruct.item1[var1]

Aside from being more consistent, bracket-notation respects the case of your keys, and does not UPPERCASE them. This is very important when, for example, you are serializing your structs to send to backend services, and similar. The only disadvantage is the additional character you have to type (2 brackets instead of 1 period).

It's a fairly opinionated topic, but having a rule to enforce either the presence or absence of meaningless-but-popular self-closed CFML tags would be a good 'un.

EG:

<cfset foo = "bar" />
<cfset bar = "foo">

Would raise a warning because of the mix of styles.

This should be something that should be settable to either require (as much as it's enforceable in CFML) self-close tags, or prohibit them.

If so, that would be good to know!

Calling rand() without first calling randomize() should cause a lint warning.

An Underscore-style html doc site should be generated from DOCS.md and placed on the gh-pages branch

Since ArrayNew(1) is equivalent to [], use of ArrayNew(1) should fail lint.

Seems like some of the struct functions are outdated. Here is a list that I think should cause warnings:

• structFind
• structGet
• structInsert
• structNew
• structUpdate

The use of "decision operators" should cause lint failures. Examples IS, IS NOT, EQ, NEQ, etc...

Boolean operations should be used instead.

Attempts to access array index of zero (or negative values) should fail lint.

Example failures:

var x = myArray[0];

myArray[0] = 1;

var x = myArray[-1];

I can't think of any time when you'd even write [0] (or have a negative constant index) in cfml.

I believe strongly that comments should not affect code execution. If I were going to use a CFScript linter, I would definitely disallow them.

I agree that they look better than function metadata as weird name/value pairs after the argument list... but I'd rather explain ugly syntax to a new programmer than that only a certain type of comments affect the way code executes.

Not sure if we'll support plugins or just want to build it into the core (or something else?) but it would be cool if we could support my CFScript Community Components project.

The use of isDefined() should probably cause a lint warning that suggests the use of structKeyExists() instead.

It might be useful if custom lint rules could be defined on a per-component basis. It could be used for situations where it is bad practice to use a component a certain way, but that doing so won't throw an error.

For instance, if you're supposed to call obj.close() after obj.open(), the linter could check for that.

This gets into some pretty insane meta-programming and I have no idea how this would be implemented, but I thought I'd bring it up anyways. Definitely falls into the "nice to have", low-priorty category.

Unnecessary use of pound signs should fail lint. Wrapping them in quotations should warn unless there are other characters included.

Example fail:

x = #y#;

Example warn:

x = "#y#";

Example pass:

x = "y is #y#";

Since both equals and colon notation can be used in the newest versions of CF, should the linter prefer one or the other?

Examples:

var myStruct = {
   myValue: "value"
};

or

var myStruct = {
   myValue = "value"
};

Both of these are valid in CF 10 and Railo 4.

Obviously it would be easiest to only support the latest Railo/Coldfusion versions (currently 4 and 10, respectively), but there might be cases where it could be useful to support multiple versions?

I could see it being helpful if the linter identified unsupported features for your version, but then again, the JIT compiler would throw an error in that case too.

Use of ampersand with numbers should fail. Constant numbers used with the ampersand sign must be wrapped with quotation marks.

Example fail:

x = 1 & 2;

Example pass:

x = "1" & "2";

I've started playing with Mocha for unit tests. What I've got so far is shared as the mocha-experimental branch.

If you're familiar with Node at all the Readme (with my modifications) should get you up to speed on running the tests. The test code itself is easily read.

I'll comment on this thread requesting feedback/etc as appropriate. Feel free to ask questions/etc here so that others who need help getting up to speed can learn from the public discussion.

Which hash() and encrypt() algorithms should not pass lint? (also for: encryptBinary() and generateSecretKey())

lint should fail if shared scope variables (application, server, session, or request) are set without being wrapped in a lock block with the appropriate scope. (it would be great if the lock type exclusive could be linted too).

lint should also fail if shared scope variables are accessed without being wrapped in duplicate().

You can either create a new issue for a specific lint rule or bring up some random stuff for discussion here. Keep in mind that this is meant to be a cfscript linter, not for cf tags.

This is kind-of a big one. Should the linter fail/warn when using unscoped variables? Is it okay to use variables without a scoping prefix if they have been declared with var?

Personally, I think the linter should fail if an unscoped variable is used which hasn't been declared with var.

Use of plus signs with constant strings should fail lint.

Example fail:

x = "1" + "2";

I'm partial to the MIT License, which to the best of my understanding is functionally equivalent to the WTFPL, with more business-friendly language. I have also used the Apache license in the past.

BSD is also popular for being more lenient than GPL. Personally, I avoid GPL.

This should fail lint

Use of reserved words outside of the proper context should not pass lint.

See: http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec173d0-7ff8.html

and: http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec173d0-7ffb.html

and: http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7785.html

use of parameterExists() should fail lint. structKeyExists() should be used instead.

using all caps for any code (variables or reserved words) should fail lint.

cfml doesn't support constants-as-variables, so the use of all caps to imply constancy is misleading at best.

So if you're not familiar, the oddly named CFEngine tool has also inspired its own linter, also named CFLint.

I would venture to guess (but it is a guess) that many more enterprise businesses are using CFEngine than businesses (of any type) are using ACF. Perhaps it would be wise to come up with another name to avoid confusion?

</$0.02>

Use of deprecated functions should fail lint. See: http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec1a60c-7fff.html

Yes, we could do it in CF, but I don't think that would work out very well considering how I personally want to use the linter (as a Sublime Text plugin). Also, I don't know of any parsers written in CF.

My top picks are: JS, Ruby, or Python.

For JS, we could use jison

Empty catch blocks should fail lint.

component output="false" should be set for components, else lint warning

This should cause a lint warning if the start_pos and end_pos are the same, since that offers no advantage over traditional array usage (myArray[index] = 'value').

IIF() should cause a failure and suggest the use of the ternary operator instead.
DE() should cause a failure.

I haven't used ORM much, so I'm not familiar with corresponding best practices. Please share your thoughts.

I don't think we should write lint rules that duplicate errors which are already thrown by the engine (for example #9 ). Seems like it would generate a fair amount of additional work that might not be necessary.

Use of incrementValue() should cause a lint warning and suggest ++ instead. (Or should it suggest +=1?)

(Also decrementValue() should be handled similarly)