Introduction
The ColdFusion CFScript style Guide (PDF) is a comprehensive, ready-to-use reference that standardizes how you write CFScript and CFML. It distills proven conventions from high-performing ColdFusion teams into clear rules, annotated examples, and practical checklists. Whether you ship on Adobe ColdFusion or Lucee, this guide helps you enforce consistent formatting, reduce Technical debt, and accelerate code reviews—while improving readability and maintainability across your codebase.
H2: Overview
The style guide codifies CFScript and CFML conventions—naming, formatting, Error handling, component design, and Security practices—so teams can align on one predictable, professional code style. It is intentionally pragmatic: every rule is backed by examples, Common pitfalls, and rationale. You can adopt it incrementally, plug it into a linter (e.g., CFlint), or use it as a training resource for new team members.
Who it’s for:
- CFML/CFScript developers on Adobe ColdFusion or Lucee
- Engineering managers standardizing Code quality
- Teams migrating from tag-based CFML to CFScript
- Consultants and contractors who need a clear, portable rule set
Key outcomes:
- Faster PR reviews and fewer style debates
- Consistency across service layers and Microservices
- Cleaner diffs and automated formatting
- Better Onboarding for new developers
H2: What You’ll Get
- The PDF (approx. 30–40 pages):
- Core conventions for CFScript and hybrid CFML
- Naming rules for variables, components (CFCs), functions, and arguments
- Formatting rules (indentation, whitespace, braces, line length)
- Component Architecture: CFC structure, access modifiers, getters/setters
- Error handling patterns with try/catch, rethrow, and logging
- Secure Database access with cfqueryparam and parameterized SQL
- Commenting and documentation style (including Javadoc-style tags)
- Module and folder layout guidelines (handlers/services/models)
- Annotated examples and anti-patterns with Refactoring tips
- Team adoption Checklist and Code review rubric
- Copy-and-paste code examples embedded throughout
- Links to optional, drop-in configurations (referenced in the PDF):
- Example .editorconfig for indentation and newline rules
- Sample cflint.json to match the guide’s rules
- Pre-commit hook script to run linting before commits
- Templates: base.cfc, service.cfc, handler.cfc, test.cfc
Note: The optional configs are referenced so you can mirror the rules in your editor/CI. If your Download includes a resources bundle, place those files at your repo root.
H2: How to Download
- Click the Download button or link provided on this page to get the ColdFusion CFScript style Guide (PDF).
- If you’re offered a bundle, choose “PDF + Configs” to receive the PDF and the optional Configuration templates.
- Save the PDF locally; for team use, commit the referenced Configuration files into your repository (see next section).
Tip: If you cannot see the download link, refresh the page or check whether your browser blocked downloads. You may also need to allow pop-ups for your site.
H2: How to Use the Style Guide
H3: Quick Start
- Read the Overview and Summary Rules sections to understand the high-level Standards.
- Apply the rules to a small module or feature branch to build familiarity.
- Adopt the included .editorconfig and cflint.json (if provided) to automate enforcement.
- Use the Code review Rubric to align your team on what “good” looks like.
- Gradually refactor legacy areas as you touch them, rather than trying to rewrite everything at once.
H5: Minimal adoption Checklist
- Configure indentation, line length, and trailing whitespace in your editor
- Enable a CFML/CFScript linter
- Enforce parameterized SQL in code review
- Standardize component and function naming
- Require try/catch around Integration points and log consistently
H3: Editor Integration
H4: Visual Studio Code (CFML Language Support)
- Install extension: CFML Language Support (by KamasamaK) and EditorConfig for VS Code.
- Add a .editorconfig at your repository root:
[*.{cfm,cfc}]
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true - VS Code settings (example):
{
“editor.tabSize”: 2,
“editor.detectIndentation”: false,
“files.trimTrailingWhitespace”: true,
“files.insertFinalNewline”: true
}
H4: IntelliJ IDEA / WebStorm (CFML plugin)
- Install the CFML plugin.
- Enable EditorConfig support (Settings > Editor > Code Style > Enable EditorConfig).
- Set JavaScript-like brace placement for CFScript and 2-space indentation to mirror the guide.
H4: Sublime Text
- Install a CFML Syntax package.
- Use the EditorConfig plugin to apply indentation and whitespace rules automatically.
H3: Linting and CI
H4: CFlint setup (example)
- Download CFlint (CFML linter).
- Add cflint.json to your repo root to align with the guide:
{
“inheritDefaultRules”: true,
“maxNumberOfProblems”: 0,
“ruleConfigs”: {
“UpperCaseConstantNames”: {“enabled”: true},
“CamelCaseFunctionNames”: {“enabled”: true},
“NoImplicitScopes”: {“enabled”: true},
“AvoidGlobalScope”: {“enabled”: true},
“MaxLineLength”: {“length”: 120}
}
} - Run CFlint locally and in CI to keep style consistent.
H4: Pre-commit hook (optional)
- In .git/hooks/pre-commit (Unix/macOS), add:
!/usr/bin/env bash
java -jar tools/cflint.jar -folder ./ -json > cflint-report.json
if [ $? -ne 0 ]; then
echo “CFlint found issues. Please fix before committing.”
exit 1
fi
H4: GitHub Actions (example)
- .github/workflows/lint.yml:
name: CFML Lint
on: [push, pull_request]
jobs:
cflint:
runs-on: ubuntu-latest
steps:- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17 - name: Run CFlint
run: java -jar tools/cflint.jar -folder ./ -text
H3: Team Adoption
- Add a “Coding Standards” section to your CONTRIBUTING.md linking to the PDF.
- Make the code review rubric part of your PR template.
- Run a 30–45 minute brown-bag session to align on key differences (e.g., brace style, naming, and error handling).
- Start with “warn only” lint rules, then move to “error” after two sprints.
H2: Best practices Highlighted in the Guide
H3: Naming and Formatting
- Use camelCase for variables and functions; PascalCase for CFCs; UPPER_SNAKE_CASE for constants.
- Keep lines ≤ 120 characters; wrap fluent chains and long SQL.
- Prefer explicit scoping (variables, arguments, local, this).
- Place braces on the same line for functions and control blocks for compactness.
Example:
component displayname=”UserService” accessors=”true” {
public any function getUserById(required numeric userId) {
var user = variables.userGateway.findById(arguments.userId);
if (!isNull(user)) {
return user;
}
throw(type=”UserNotFound”, message=”User #arguments.userId# not found”);
}
}
H3: Components and Functions
- One CFC per responsibility; keep functions focused and small.
- Use accessors=”true” for simple getters/setters or write explicit methods if validation is needed.
- Mark internal functions as private or package to reduce surface area.
H3: Error Handling and Logging
- Wrap integration boundaries (DB, HTTP, file I/O) with try/catch.
- Catch specific exceptions; rethrow or wrap with context.
- Log with sufficient metadata (userId, requestId, correlationId).
Example:
try {
result = httpService.get(url=endpoint, timeout=10);
} catch (any e) {
log.error(“HTTP call failed”, { endpoint=endpoint, cause=e.message });
throw(type=”ExternalServiceError”, message=”Failed HTTP call”, detail=e.detail);
}
H3: Security and Database
- Always parameterize SQL with cfqueryparam to prevent SQL injection.
- Validate and normalize user input at boundaries.
- Avoid leaking stack traces; provide user-friendly messages.
Example:
queryExecute(
“SELECT id, email FROM users WHERE id = :id”,
{ id = { value: arguments.userId, cfsqltype: “cf_sql_integer” } },
{ datasource = application.datasource }
);
H2: Benefits and Use Cases
- Saves time in code reviews: The guide eliminates subjective debates about Syntax and naming, letting reviewers focus on correctness and Architecture.
- Reduces bugs and regressions: Consistent patterns for error handling, scoping, and SQL parameterization prevent common defects.
- Improves Onboarding: New developers can ramp up quickly with a single, authoritative coding standard.
- Enables Automation: With a matching .editorconfig and cflint.json, teams can enforce rules automatically in editors and CI pipelines.
- Ideal for Refactoring projects: Use the guide to normalize Legacy code incrementally, improving readability and testability sprint by sprint.
- Cross-vendor portability: The rules are compatible with Adobe ColdFusion and Lucee, making multi-environment teams more efficient.
H2: Supported Environments
- Adobe ColdFusion: 2018, 2021, 2023
- Lucee: 5.x and later
- Editors: VS Code, IntelliJ IDEA/WebStorm (CFML plugin), Sublime Text (with CFML package)
- CI: GitHub Actions, GitLab CI, Azure Pipelines, Jenkins (via Java/CFlint)
Note: Some linter rule sets may vary by version. Adjust cflint.json or your chosen tool accordingly.
H2: Key Takeaways
- A shared, opinionated CFScript/CFML standard accelerates delivery and improves quality.
- The PDF includes actionable rules, examples, and checklists you can adopt immediately.
- Pair the guide with editor settings and linting to automate code style adherence.
- Focus on steady, incremental adoption rather than “big bang” rewrites.
- Use the included review rubric to make code reviews faster and more consistent.
H2: FAQ
H4: Is this style guide compatible with both Adobe ColdFusion and Lucee?
Yes. The conventions are vendor-agnostic and apply to CFScript and CFML on both Adobe ColdFusion and Lucee. Where there are vendor differences, the guide provides notes or alternatives.
H4: Do I need to install anything to use the PDF?
No installation is required to use the PDF itself. For automated enforcement, you can optionally install a linter (such as CFlint) and enable EditorConfig in your editor or CI.
H4: Can I customize the rules for my team?
Absolutely. Treat the guide as a strong baseline. You can tailor sections—such as max line length, brace style, or naming variants—to fit your existing conventions. If you adjust rules, keep the changes documented and consistent.
H4: What if our codebase mixes tag-based CFML and CFScript?
The guide supports hybrid projects. It prioritizes CFScript for new development and includes conventions for tag-based CFML where appropriate, plus Migration tips for gradually moving to CFScript.
H4: How do we roll this out without slowing the team?
Adopt the editor and lint rules in “warn” mode, start with a single module, and leverage the code review rubric. Fix style issues as you touch files rather than running a massive one-time reformat across the entire repo.
