oliverdavies.uk/content/node.ff8d6ab3-e544-4f38-9d76-7206e7e4d9fe.yml

110 lines
4.4 KiB
YAML
Raw Normal View History

2025-07-10 00:14:12 +01:00
uuid:
- value: ff8d6ab3-e544-4f38-9d76-7206e7e4d9fe
langcode:
- value: en
type:
- target_id: daily_email
target_type: node_type
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
- value: '2025-05-11T09:00:26+00:00'
revision_uid:
- target_type: user
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: { }
status:
- value: true
uid:
- target_type: user
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
- value: |
Custom coding standards and conventions
created:
- value: '2023-12-11T00:00:00+00:00'
changed:
- value: '2025-05-11T09:00:26+00:00'
promote:
- value: false
sticky:
- value: false
default_langcode:
- value: true
revision_translation_affected:
- value: true
path:
- alias: /daily/2023/12/11/custom-coding-standards-and-conventions
langcode: en
body:
- value: |
<p>Open-source projects like Drupal and Symfony have their own published coding standards and conventions.</p>
<p>For example, from <a href="https://symfony.com/doc/current/contributing/code/standards.html">Symfony's coding standards</a>:</p>
<ul>
<li>Prefix all abstract classes with <code>Abstract</code> except PHPUnit <code>*TestCase</code>.</li>
<li>Suffix interfaces with <code>Interface</code>;</li>
<li>Suffix traits with <code>Trait</code>;</li>
</ul>
<p>And from <a href="https://www.drupal.org/docs/develop/standards/php/php-coding-standards">Drupal's</a>:</p>
<ul>
<li>Use an indent of 2 spaces, with no tabs.</li>
<li>Lines should have no trailing whitespace at the end.</li>
<li>Variables should be named using lowercase, and words should be separated either with uppercase characters (example: <code>$lowerCamelCase</code>) or with an underscore (example: <code>$snake_case</code>). Be consistent; do not mix camelCase and snake_case variable naming inside a file.</li>
</ul>
<p>But what about within custom applications?</p>
<p>Do you have your own agreed coding standards and conventions to keep the code consistent?</p>
<p>Do you explicitly follow the published coding standards, customise them, or follow something else?</p>
<h2 id="here%27s-the-thing">Here's the thing</h2>
<p>Do you know where to put new custom modules, how to name them and what conventions to follow when writing code?</p>
<p>Do you know where to add a new stylesheet to your theme?</p>
<p>If not, or it's implied, it's worth writing it down and being explicit - either within your project's or company's documentation or publicly.</p>
format: full_html
processed: |
<p>Open-source projects like Drupal and Symfony have their own published coding standards and conventions.</p>
<p>For example, from <a href="https://symfony.com/doc/current/contributing/code/standards.html">Symfony's coding standards</a>:</p>
<ul>
<li>Prefix all abstract classes with <code>Abstract</code> except PHPUnit <code>*TestCase</code>.</li>
<li>Suffix interfaces with <code>Interface</code>;</li>
<li>Suffix traits with <code>Trait</code>;</li>
</ul>
<p>And from <a href="https://www.drupal.org/docs/develop/standards/php/php-coding-standards">Drupal's</a>:</p>
<ul>
<li>Use an indent of 2 spaces, with no tabs.</li>
<li>Lines should have no trailing whitespace at the end.</li>
<li>Variables should be named using lowercase, and words should be separated either with uppercase characters (example: <code>$lowerCamelCase</code>) or with an underscore (example: <code>$snake_case</code>). Be consistent; do not mix camelCase and snake_case variable naming inside a file.</li>
</ul>
<p>But what about within custom applications?</p>
<p>Do you have your own agreed coding standards and conventions to keep the code consistent?</p>
<p>Do you explicitly follow the published coding standards, customise them, or follow something else?</p>
<h2 id="here%27s-the-thing">Here's the thing</h2>
<p>Do you know where to put new custom modules, how to name them and what conventions to follow when writing code?</p>
<p>Do you know where to add a new stylesheet to your theme?</p>
<p>If not, or it's implied, it's worth writing it down and being explicit - either within your project's or company's documentation or publicly.</p>
summary: null
field_daily_email_cta: { }