Coding Standards for PHP, JavaScript & Magento: A 2026 Guide

Your team writes good code. Your team also has three different “good code” definitions, depending on which dev picked up the ticket. The first dev wraps every method in a defensive null-check. The second skips them because PSR-12 type declarations make most of them redundant. The third runs phpcs --standard=Magento2, fixes whatever it flags, and ships. None of them are wrong. They are working from different mental rulebooks, and the cost is the friction inside every code review, every merge, every release.

A coding standard is the thing that turns those three rulebooks into one. Not a 200-page document nobody opens. A small, enforced set of conventions wired into the IDE, the pre-commit hook, and CI – so the conversation in code review stops being about brace placement and starts being about logic. For PHP teams running Magento (Adobe Commerce) or any modern PHP 8.x stack, that means PSR-12 plus the Magento Coding Standard. For the JavaScript layer, it means a published style guide (Airbnb, Google, or Standard) wired into ESLint. For everything, it means tooling that makes the standard cheaper to follow than to ignore.

Overview

• PSR-12 is the current accepted PHP-FIG coding style standard – it replaces PSR-2 and is the baseline every modern PHP project should follow.
• The Magento Coding Standard is the Magento2 PHP_CodeSniffer ruleset published by Adobe – install it, run vendor/bin/phpcs --standard=Magento2 app/code, and the rules check themselves.
• Coding standards in 2026 carry more weight than they did three years ago. 84% of developers use AI assistants, only 29% trust the output – the standard is the gate that keeps Copilot- and Cursor-generated code from reaching production with subtle defects.

Why coding standards matter: the dev-team-friction case

Most engineering managers do not adopt a coding standard because they want pretty code. They adopt one because the cost of not having one shows up everywhere else. Code review takes longer because each reviewer applies a personal style. New hires are slower to ramp because the codebase has no consistent shape. AI assistants generate code that matches the loudest pattern in the file, which is sometimes the wrong pattern. Refactors stall because nobody can agree on what “consistent” means.

The 2025 Stack Overflow Developer Survey shows where this lands. 84% of developers now use or plan to use AI tools, up from 76% the year before, but only 29% trust those tools to be accurate – down from 40%. 66% name “AI solutions that are almost right, but not quite” as their biggest frustration, and 45% say debugging AI-generated code is more time-consuming than writing it from scratch (2025 Stack Overflow Developer Survey). A coding standard does not solve AI’s accuracy problem. It does make the gap between “almost right” and “right” easier to catch, because the wrong code now visibly breaks a known rule.

The benefits read short in a slide and large in a year:

• Faster code review. Reviewers focus on logic, not formatting.
• Cheaper onboarding. A new dev can read your code on day one because it follows a published spec they already know.
• Lower defect rate. PSR-12 type declarations, Magento Coding Standard’s raw-SQL detection, and OWASP’s input-validation checklist all close defect classes before they reach production.
• AI-safer development. Standards make Copilot, Cursor, and Claude output reviewable instead of subjectively “kind of OK.”

Teams running Magento 2 performance optimization hit this wall fastest, because JS bundling fights with inconsistent module conventions long before the team agrees there is a problem.

What goes inside a coding standard

A useful coding standard covers six concrete areas. Anything beyond these is usually opinion dressed up as rule.

• Naming. Classes, methods, variables, constants, files. Descriptive over short. No xx, temp1, data2. PHP follows StudlyCaps for classes, camelCase for methods, UPPER_SNAKE for constants (PSR-1). JavaScript follows the same camelCase convention for variables and functions, PascalCase for classes and React components.
• Formatting. Indentation (PSR-12 mandates 4 spaces for PHP, most JS standards use 2), line length (PSR-12 soft cap 120 chars), brace placement, blank-line rules, trailing newlines.
• Type declarations and visibility. PSR-12 requires explicit visibility on every property and method. Method type declarations close a whole class of runtime errors.
• Documentation. PHPDoc on every public method – at minimum @param, @return, @throws. JS gets the same treatment via JSDoc.
• Architecture rules. Where business logic lives. What can be called from where. The Magento Coding Standard, for instance, flags raw SQL inside a model as a violation, because raw SQL belongs in a resource model.
• Security boundaries. Input validation, output encoding, secret handling – the OWASP layer. Most teams treat this as a separate document, but the rules are coding standards in disguise.

The PSR-12 spec itself is 8,000 words and reads like a contract (php-fig.org/psr/psr-12). You do not need to memorise it. You need to install the standard once, configure your IDE to apply it on save, and configure the pre-commit hook to fail on violations. The rules then enforce themselves.

Standards by language: PHP, JavaScript, Liquid

PHP: PSR-12 + the Magento Coding Standard

For any modern PHP project, the baseline is PSR-12. The PHP-FIG defines it as an “Extended Coding Style,” and it replaces the older PSR-2. The rules that matter most in practice:

• 120-character soft line limit, hard limit not specified.
• 4-space indentation. Never tabs. Never mixed.
• Unix LF line endings, single trailing newline, no trailing whitespace.
• Opening brace on the same line for control structures, on a new line for classes and methods.
• Visibility declared on every property and method (public, protected, private).
• One blank line after the namespace declaration, one blank line after the use declarations.
• Method type declarations: no space between question mark and type for nullable types (?int, not ? int).

The PSR-12 standard is the floor. On a Magento or Adobe Commerce project, the floor moves up to the Magento Coding Standard – Adobe’s Magento2 ruleset for PHP_CodeSniffer. It includes PSR-12 plus rules specific to the Magento codebase: @api boundary enforcement, raw-SQL detection, Magento-specific docblock requirements, escape-output checks in Knockout templates, and module dependency rules. Cover it in detail in the next section.

JavaScript: pick one, wire it to ESLint

JavaScript has no single accepted standard the way PHP has PSR. It has three credible options, and the right pick depends on your stack.

• Airbnb JavaScript Style Guide. The de-facto community standard – 100k+ GitHub stars, the eslint-config-airbnb package pulls ~5 million npm downloads per month, and the State of JS survey shows 55% of JS developers report using it. Strong React conventions, opinionated on ES6+. The right pick for most modern eCommerce frontends, including Hyvä themes on Magento and Next.js / Remix headless storefronts.
• Google JavaScript Style Guide. Closure-Compiler-aware, heavier on JSDoc, opinionated on naming. The right pick if your team also writes TypeScript at scale and wants close alignment with Google’s tooling family.
• Standard.js. Zero-configuration, no semicolons, opinionated minimalism. Less common in eCommerce, more common in Node-only backends.

The choice matters less than the wiring. Whatever you pick, install ESLint, install the matching eslint-config-airbnb (or equivalent) package, commit the config to the repo, and add a pre-commit hook (or husky + lint-staged) that runs ESLint on staged JS files. The rule is identical to PHP: the standard enforces itself, or it does not exist.

For a Luma-to-Hyvä rewrite, the JS conventions take over – Hyvä is Alpine and Tailwind, not Knockout, and the Luma bottleneck rewrite we did for a global home brand depended on a clean Alpine.js convention before any of the performance work paid off.

Liquid (Shopify): Theme Check is the standard

Shopify does not publish a written coding standard in the PSR sense, but it provides Theme Check – a linter for Liquid that catches dead code, missing translations, unclosed tags, deprecated filters, and accessibility issues (Shopify Liquid reference). For any Shopify Plus team, Theme Check on pre-commit is the equivalent of phpcs --standard=Magento2 on Magento – it is the standard the platform itself publishes, and it should run before every push.

Magento / Adobe Commerce coding standards in practice

The Magento Coding Standard is the one place a coding-standards discussion stops being abstract and starts producing a useful command-line output. It is a PHP_CodeSniffer ruleset called Magento2, published by Adobe at github.com/magento/magento-coding-standard and documented at developer.adobe.com/commerce/php/coding-standards.

Install it once on a Magento 2 or Adobe Commerce project:

composer require --dev magento/magento-coding-standard
vendor/bin/phpcs --config-set installed_paths ../../magento/magento-coding-standard

Then run it on any module, theme, or extension:

vendor/bin/phpcs --standard=Magento2 app/code/Vendor/Module

The output is a list of violations with file, line, severity, and the rule name – exactly what a developer needs to fix the problem without guessing. Hook the same command into your CI pipeline (GitHub Actions, GitLab CI, Bitbucket Pipelines) and the build fails on any new violation. From that point, the standard is not a culture problem – it is a CI gate.

The Magento Coding Standard adds three classes of rules on top of PSR-12 that matter specifically for Adobe Commerce projects:

• @api boundary enforcement. Methods marked @api are public contracts. Changing their signature without a major-version bump is a violation. The sniffer catches this before customers find it.
• Raw SQL detection. A raw SELECT * FROM inside a model is flagged. Magento data should pass through the resource model and the framework, not raw queries.
• JS / Knockout conventions. The same standard covers Magento’s frontend JS layer – jQuery patterns, Knockout data-bind use, and module dependency rules under requirejs-config.js.

For teams running Adobe Commerce specifically, scandiweb’s Magento code audit walkthrough breaks down exactly which phpcs rules a merchant should run before every release, and how to read the output as a triaged backlog rather than a wall of red. The same standard underpins every Magento development project our team delivers for merchants on Adobe Commerce or Magento Open Source.

Enforcement: linters, pre-commit hooks, CI

A written standard nobody enforces is worse than no standard – it generates audit trails of violations without changing behavior. The enforcement loop has three concrete gates. Run them in this order:

Gate 1: IDE on save

Configure PHPStorm, VS Code, or your editor of choice to run phpcbf (the PHP_CodeSniffer auto-fixer) or php-cs-fixer on save, with the Magento2 or PSR-12 standard wired in. For JavaScript, install the ESLint plugin and tick “format on save.” Most violations now never reach the commit.

Gate 2: Pre-commit hook

Install Husky (Node) or a Git pre-commit hook directly, and wire it to run the relevant linters on staged files only. lint-staged makes this clean: it runs phpcs on staged PHP files and eslint --fix on staged JS files, blocks the commit if anything fails, and uses less than 2 seconds of developer time.

Gate 3: CI gate

Add a job to your CI pipeline that runs the full lint suite on the pull request:

# GitHub Actions example
- name: Run Magento Coding Standard
  run: vendor/bin/phpcs --standard=Magento2 --report=summary app/code
- name: Run ESLint
  run: npx eslint --max-warnings 0 .

Mark the job as required on the protected branch. Any PR that fails the lint blocks merge. No exceptions.

Code review checklist

Tooling catches the mechanical. Code review catches the semantic. Keep the review checklist short – three to five items max, all things tooling cannot evaluate:

• Does the change have a test? (or a documented reason for skipping)
• Is the change behind the right module boundary? (@api contracts respected)
• Are inputs validated and outputs encoded? (OWASP layer)
• Does the change introduce new dependencies, and if so, why?

If you are weighing the platform choice itself, the Adobe Commerce vs Magento Open Source breakdown maps which coding standards apply to each tier – the Magento Coding Standard is identical across both, but Adobe Commerce includes additional B2B and PWA Studio rule packs the Open Source teams will not see.

Secure coding standards (OWASP-aligned)

Security rules are coding standards too – they are the standards your team will be most embarrassed to skip when a postmortem lands. The reference is the OWASP Secure Coding Practices Quick Reference Guide (note: OWASP migrated this content into the broader OWASP Developer Guide, so the current canonical version lives there). The checklist covers eight areas worth wiring into your code review and pre-commit gates:

• Input validation. Every input from a request, an API, or a file is untrusted by default. Validate type, length, format, and range before use. On Magento, this means \Magento\Framework\Filter\FilterManager and the form validators – not custom regex.
• Output encoding. Every output to a browser, an email, or a log line is encoded for its destination. The Magento Coding Standard’s Magento2.Security.LanguageConstruct.DirectOutput rule flags raw echo without encoding.
• Authentication and session management. Use the framework’s auth, not your own. On Magento, this is the customer session API, on PHP-native, it is the modern password_hash() + password_verify() plus PASETO or JWT for stateless flows.
• Access control. Authorise every privileged action. Do not rely on hiding the URL.
• Cryptographic practices. Use the standard library. Never roll your own crypto.
• Error handling and logging. Never leak stack traces or DB schemas to the user. Log enough to debug, never enough to enable attack.
• Data protection. Encrypt sensitive data at rest. Mask in logs. Truncate before audit.
• File and resource management. Validate file uploads. Whitelist extensions and MIME types. Quarantine.

Treat these as enforceable rules in code review, not as suggestions. Most teams who get bitten on a security review got bitten on input validation or output encoding – both of which are catchable by tooling if you wire the rules in. For Adobe Commerce stores already in production, scandiweb’s Magento support team runs the same OWASP-aligned checks against every release as part of the standard maintenance loop.

Coding standards in the AI era: Copilot, Cursor, Claude

This is the section that did not exist three years ago. Today, ~51% of professional developers use AI coding assistants daily, and GitHub Copilot, Cursor, and Claude Code together account for the majority of workplace AI-coding adoption (uvik.net AI coding assistant statistics, citing JetBrains 2026). The productivity number cited most often is ~3.6 hours/week saved per developer using AI tools.

The harder number is the one from the Stack Overflow survey: 66% of developers name “AI solutions that are almost right, but not quite” as the single biggest frustration with AI tools, and 45% say debugging AI-generated code takes more time than writing it from scratch. The AI does not produce wrong code – it produces code that passes the test you wrote but fails on the test you forgot to write.

Coding standards are the cheapest guardrail against this failure mode. Three concrete patterns work:

• Lint the AI output as if it were a junior dev’s first PR. Run phpcs --standard=Magento2 on every AI-generated commit. Run ESLint with --max-warnings 0. The AI accepts the rules without arguing.
• Require the AI to cite the rule. When you prompt Copilot, Cursor, or Claude, give it the standard in the system prompt: “Follow PSR-12. Use Magento Coding Standard conventions. Type declarations required.” Most assistants now respect this consistently.
• Review the diff, not the result. AI-generated code reads as plausible. The diff against your standard tells you whether it actually is.

We documented one of these workflows in AI Agent Bites #7, where a Cursor + Google Stitch loop produced a production landing page in under an hour – a workflow that only worked because the coding standard was baked into the prompt and the lint gates caught the cases where Cursor drifted. Our broader AI development practice now treats coding-standard injection as a default prompt pattern across every project.

How mature is your coding standards setup?

Most teams stand somewhere on the ladder below. The cheapest move is to find your level and step up by one. The five rungs:

• Level 0 – No standard. Every dev styles their own way. Code review is a personality test. Linter present, no one runs it.
• Level 1 – Written standard, no enforcement. Confluence page exists. Nobody reads it. Code reviews still argue about formatting.
• Level 2 – IDE-level enforcement. PHPStorm or VS Code applies the standard on save. New code conforms, legacy does not.
• Level 3 – Pre-commit + IDE. Husky or git hooks block bad commits. Refactor projects gradually pull legacy into compliance.
• Level 4 – CI gate + pre-commit + IDE. Pull requests fail on any violation. The standard is now a contract, not a culture.
• Level 5 – Standard + security review + AI-prompt integration. OWASP layer wired into the same gates. AI prompts carry the standard. Drift to “almost right” code is caught at the pre-commit gate, not in production.

A team at Level 0 should pick PSR-12 (or Airbnb for JS-only stacks), wire it into the IDE, and move from Level 1 to Level 2 in a single sprint. The Level 4 to Level 5 jump is the one that earns its cost in 2026 specifically, because of the AI-assistant defect class.

Frequently asked questions

What is a coding standard?

A coding standard is a published set of rules that define how code should be written – naming, formatting, type declarations, documentation, architecture boundaries, and security practices. The point is consistency across a team, not aesthetic preference. For PHP, the most widely accepted general standard is PSR-12. For Magento projects, the Magento Coding Standard published by Adobe applies on top of PSR-12.

What is the difference between PSR-12 and PSR-2?

PSR-12 is the current accepted PHP-FIG coding style standard. It extends and replaces PSR-2, adding rules for PHP 7+ features that PSR-2 predates: nullable type declarations, return type declarations, anonymous classes, and the use of declare(strict_types=1). New PHP projects should target PSR-12 directly. Existing PSR-2 projects can migrate file-by-file using php-cs-fixer with the @PSR12 rule set.

How do I run the Magento Coding Standard?

Install the standard once via Composer (composer require --dev magento/magento-coding-standard), then point PHP_CodeSniffer at it: vendor/bin/phpcs --config-set installed_paths ../../magento/magento-coding-standard. From then on, run vendor/bin/phpcs --standard=Magento2 app/code/Vendor/Module to lint any module. Wire the same command into your pre-commit hook and CI to enforce it automatically.

Which JavaScript style guide should an eCommerce team use?

For most modern eCommerce frontends – Hyvä themes on Magento, headless storefronts on Next.js or Remix, or any React-heavy Shopify Plus theme – the Airbnb JavaScript Style Guide is the strongest default. It covers ES6+, React conventions, and accessibility, and the eslint-config-airbnb package is well-maintained. Google’s style guide is a better fit for teams already in Google’s tooling ecosystem with TypeScript at scale.

Are coding standards still useful when developers use AI assistants?

More useful, not less. Stack Overflow’s 2025 survey reports that 66% of developers name “AI output that is almost right, but not quite” as their biggest frustration with AI tools, and 45% say debugging AI-generated code takes longer than writing it from scratch. A coding standard wired into pre-commit hooks and CI catches the cases where AI assistants generate plausible-looking code that violates the rules, before the code reaches production.

What is the difference between a coding standard and clean code?

A coding standard is a published, enforceable set of rules – PSR-12, the Magento Coding Standard, Airbnb JS. “Clean code” is a quality goal that includes readability, single responsibility, low coupling, and good naming. A coding standard helps you achieve clean code but does not guarantee it. You can follow PSR-12 perfectly and still write a tangled 300-line method. The standard is the floor, clean code is the ceiling.

How do I introduce a coding standard to an existing legacy codebase?

Three steps. First, run the standard in report-only mode (phpcs --report=summary) to see the size of the gap. Second, add the standard as a CI gate for new and changed files only – do not block the whole repo on day one. Third, schedule a recurring “lint cleanup” hour each sprint where the team auto-fixes (phpcbf) a slice of legacy. Most teams clear a year-old codebase in two to three months without halting feature work.

If three of your devs are running three different “phpcs” configurations on the same Magento codebase, the question is not which one is right – it is what your team agrees to enforce, and how. Request a code audit on your PHP and Magento stack and we will tell you exactly which rules you are already breaking, which ones to gate at CI first, and where the AI-assisted commits are drifting against PSR-12 and the Magento Coding Standard.

Share on: