Coding Standards

QUIQQER packages use shared coding standards so packages stay readable, reviewable, and maintainable across teams.

PHP

Use PSR-12 for PHP code. PHPCS is the standard tool for checking PHP code style in QUIQQER packages.

PSR-12 extends PSR-2 and requires PSR-1. It defines formatting, namespaces, imports, class structure, method formatting, control structures, and other PHP style rules.

Practical rules:

• Use strict, readable formatting.
• Keep imports organized.
• Use consistent class, method, and constant naming.
• Do not mix style-only changes with behavior changes.
• Run the package style checks before pushing when tooling is available.

QUIQQER packages commonly manage development tools with PHIVE. After tool initialization, PHPCS is available through the package-local tool wrapper:

./tools/phpcs

Composer scripts can wrap that command, but the tool itself is provided by PHIVE:

{
  "scripts": {
    "dev:lint:style": "./tools/phpcs"
  }
}

When PHPCS reports violations, fix the code style before pushing. Keep style-only fixes in their own style: commits unless they are directly part of the changed lines in an atomic feature or bug-fix commit.

Static Analysis

Use PHPStan for static analysis when the package provides it. PHPStan is also managed as a package-local PHIVE tool.

Run PHPStan through the local tool wrapper:

./tools/phpstan

Composer scripts can wrap PHPStan in the same way:

{
  "scripts": {
    "dev:lint:phpstan": "./tools/phpstan"
  }
}

PHPStan findings should be treated as code quality issues, not as formatting issues. Fix the underlying type, API, or control-flow problem instead of hiding it unless the package has a documented reason for an ignore.

JavaScript

QUIQQER packages commonly use JSHint with the shared QUIQQER rule set.

Practical rules:

• Keep package JavaScript compatible with the package's current frontend stack.
• Define package-specific globals in .jshintrc when needed.
• Do not add unrelated formatting changes to feature or bug-fix commits.
• Run JavaScript linting when the package provides a script or tool for it.

If a package needs rules that differ from the shared defaults, add a .jshintrc in the package root and keep the exception local to that package.

Repository Scripts

Current packages often define PHIVE-managed tools and optional Composer script wrappers:

{
  "scripts": {
    "test": [
      "@dev:lint",
      "@dev:phpunit"
    ],
    "dev:lint": [
      "@dev:lint:phpstan",
      "@dev:lint:style"
    ],
    "dev:lint:phpstan": "./tools/phpstan",
    "dev:lint:style": "./tools/phpcs"
  }
}

Use the tools and wrappers provided by the package you are working on. Do not assume every package has exactly the same tool set.

Typical package checks:

• phive install --temporary installs package-local tools into ./tools/.
• ./tools/phpcs runs PHPCS.
• ./tools/phpstan runs PHPStan.
• ./tools/phpunit runs PHPUnit when configured.
• ./tools/phpcbf can fix PHPCS-fixable style issues.
• ./tools/captainhook installs configured Git hooks.
• composer test can wrap the package test stack when configured.

Code Review Expectations

Before opening a merge request:

• Keep commits atomic.
• Use valid commit messages.
• Run the available lint and test commands.
• Fix PHPCS and PHPStan findings or document why a finding cannot be fixed yet.
• Avoid unrelated formatting changes.
• Document behavior changes in the merge request.
• Add or update tests when package tooling supports it.