Uiteindelijk maakt het niet zoveel uit welke standaard je kiest, zolang je je er maar aan houdt. Alle (eigen) code die in een project wordt geschreven, moet zich eraan houden. Discussies over welke standaard het beste is, kosten vaak meer energie dan het werk zelf dan wanneer je je gewoon aan de gekozen standaard houdt. Meningen komen en gaan, maar door de community gedefinieerde standaarden zoals PSR-1, PSR-2, PSR-12 en tot slot PER-2 worden breed geaccepteerd.
Waarom
Door één standaard te hanteren heeft alle code dezelfde cognitieve belasting voor de (menselijke) lezer. Omdat code vaker gelezen dan geschreven wordt, maakt dit het werken met de code gemakkelijker.
Het volgen van een door de community gedreven standaard maakt het eenvoudiger om nieuwe developers uit die community in te werken op een bestaand project. Dit verlicht de last voor nieuwe developers om een nieuwe standaard te moeten leren.
De uniformiteit die door de gekozen standaard wordt afgedwongen heeft als bijkomend effect dat je je ook aan meer gangbare coding guidelines uit de industrie houdt.
Gebruik deze skill om de richtlijn rechtstreeks toe te passen met een AI-assistent.
Use this skill when a Laravel task touches this best practice. It is self-contained so it can be installed independently by Laravel Boost or another agent-skill system.
## Core Guidance
In the end it doesn't really matter *which* standard you choose, as long as you stick to it. All (own) code written in a project must adhere to it. Discussions on which standard can often times take more energy out of the actual work than just adhering to the chosen standard. Opinions come and go, but community defined standards like PSR-1, PSR-2, PSR-12 and finally PER-2 are broadly accepted.
## Why It Matters
- By implementing a single standard all code has the same amount of cognitive load for the (human) reader. As code is more often read than it is written, this eases with working with the code.
- Following a community driven standard allows for easier ramping up of new developers from that community to an existing project. This lessens the burden on new developers having to learn a new standard.
- Uniformity enforced by the chosen standard also has side effects of adhering to more industry standard coding guidelines.
## Apply When
- Projects of all sizes
## Be Careful When
- N/A
## Canonical Source
- Full best practice: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/code-standards/adhere-to-a-single-standard/BEST_PRACTICE.md
- Dutch translation: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/code-standards/adhere-to-a-single-standard/translations/nl.md
## Workflow
1. Inspect the user's Laravel code before recommending changes.
2. Identify the narrow rule from this best practice that applies to the task.
3. Prefer Laravel's built-in conventions and documented APIs over custom abstractions.
4. Keep examples focused on this practice; reference other skills or practices when the task crosses boundaries.
5. Verify code changes with the project's available tests, linters, static analysis, or framework checks.
## Review Checklist
- The recommendation is Laravel-specific and grounded in this practice.
- Code examples use realistic Laravel file names, class names, and method names.
- The advice avoids mixing unrelated architecture, deployment, security, or testing topics.
- Related practices are mentioned when useful, but not re-explained in full.
- Dutch output, when requested, keeps framework and API names intact.
Cookies & privacy
Kies voor een optimale ervaring
We gebruiken externe tools om jouw ervaring op onze website te verbeteren. Lees meer
in onze
privacy- en cookieverklaring.
