82 lines
4.1 KiB
YAML
82 lines
4.1 KiB
YAML
uuid:
|
|
- value: 2743d645-0679-4862-91b6-1f77f218a5fd
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-06-24T22:18:48+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: 'Consistency is key'
|
|
created:
|
|
- value: '2025-06-21T22:12:37+00:00'
|
|
changed:
|
|
- value: '2025-06-24T22:18:48+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/06/21/consistency-key
|
|
langcode: en
|
|
body:
|
|
- value: |-
|
|
Yesterday, I wrote about some of my [thoughts about the Action pattern](/daily/2025/06/20/my-thoughts-action-pattern) that's become popular with PHP Developers.
|
|
|
|
I showed an example based on the `AddRandomCtaToDailyEmail` action class from my website.
|
|
|
|
But, how should these classes be named?
|
|
|
|
Should my example by `AddRandomCtaToDailyEmail` or `AddRandomCtaToDailyEmailAction`?
|
|
|
|
Should my `Ctas` class - a collection of "Call to Action" nodes - be `Ctas` or `CtaCollection`?
|
|
|
|
In these examples, I think the class name is descriptive enough that it doesn't need to be suffixed.
|
|
|
|
In other cases, such as Controller classes, Interfaces, and classes that follow other design patterns such as Repositories, Factories and Builders, I will prefix to make it clearer which pattern they implement.
|
|
|
|
Some projects have an existing coding standard and guidelines to follow, and some will have contribution documentation or a style guide to explain which patterns to follow and how to name things so changes are consistent with the rest of the project.
|
|
|
|
Consider doing the same for your software.
|
|
|
|
Document your rules and conventions for your current and future team members.
|
|
|
|
The [Spatie Guidelines](https://spatie.be/guidelines) are a great example to follow.
|
|
|
|
Then, make sure they are followed when the code is being reviewed, either in a pull/merge request or during a pair or mob programming session.
|
|
|
|
Having consistent approaches makes projects more robust and easier to work on.
|
|
format: markdown
|
|
processed: |
|
|
<p>Yesterday, I wrote about some of my <a href="/daily/2025/06/20/my-thoughts-action-pattern">thoughts about the Action pattern</a> that's become popular with PHP Developers.</p>
|
|
<p>I showed an example based on the <code>AddRandomCtaToDailyEmail</code> action class from my website.</p>
|
|
<p>But, how should these classes be named?</p>
|
|
<p>Should my example by <code>AddRandomCtaToDailyEmail</code> or <code>AddRandomCtaToDailyEmailAction</code>?</p>
|
|
<p>Should my <code>Ctas</code> class - a collection of "Call to Action" nodes - be <code>Ctas</code> or <code>CtaCollection</code>?</p>
|
|
<p>In these examples, I think the class name is descriptive enough that it doesn't need to be suffixed.</p>
|
|
<p>In other cases, such as Controller classes, Interfaces, and classes that follow other design patterns such as Repositories, Factories and Builders, I will prefix to make it clearer which pattern they implement.</p>
|
|
<p>Some projects have an existing coding standard and guidelines to follow, and some will have contribution documentation or a style guide to explain which patterns to follow and how to name things so changes are consistent with the rest of the project.</p>
|
|
<p>Consider doing the same for your software.</p>
|
|
<p>Document your rules and conventions for your current and future team members.</p>
|
|
<p>The <a href="https://spatie.be/guidelines">Spatie Guidelines</a> are a great example to follow.</p>
|
|
<p>Then, make sure they are followed when the code is being reviewed, either in a pull/merge request or during a pair or mob programming session.</p>
|
|
<p>Having consistent approaches makes projects more robust and easier to work on.</p>
|
|
summary: ''
|
|
field_daily_email_cta:
|
|
- target_type: node
|
|
target_uuid: c74de3cf-5362-4d08-935a-a9d0d22fcb94
|