80 lines
3.6 KiB
YAML
80 lines
3.6 KiB
YAML
uuid:
|
|
- value: b2e7fd1a-40f8-40fc-9304-54385e3dcb6d
|
|
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:07+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: 'find vs. get'
|
|
created:
|
|
- value: '2024-09-05T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:07+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2024/09/05/find-vs-get
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>This week, I spoke with <a href="https://www.daveliddament.co.uk">Dave Liddament</a> to record an upcoming episode of <a href="/podcast">the Beyond Blocks podcast</a>.</p>
|
|
|
|
<p>In that conversion, we started to talk about conventions, specifically unwritten conventions used within projects.</p>
|
|
|
|
<p>Dave mentioned on some of his projects, they have a convention for when to use <code>get</code> or <code>find</code> method prefix names.</p>
|
|
|
|
<p>For example, in a <code>UserRepository</code> class, a method like <code>findUserByEmail()</code> implies that a matching user may not be found.</p>
|
|
|
|
<p>Alternatively, <code>getUserByEmail()</code> implies that you're getting a user and will always be one found and returned.</p>
|
|
|
|
<p>This interested me and I <a href="https://tuhrig.de/find-vs-get">found a blog post by Thomas Uhrig</a> on find vs. get, which I've read since the recording.</p>
|
|
|
|
<p>In the context of the episode, we discussed how conventions like this can be codified and written down and checkable with static analysis tools, but it got me thinking about conventions I've consciously or unconsciously followed, as well as the impact of changing a small word in a method name on its behaviour.</p>
|
|
|
|
<p>What about you?</p>
|
|
|
|
<p>Do you have similar conventions that you follow in your applications?</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>This week, I spoke with <a href="https://www.daveliddament.co.uk">Dave Liddament</a> to record an upcoming episode of <a href="/podcast">the Beyond Blocks podcast</a>.</p>
|
|
|
|
<p>In that conversion, we started to talk about conventions, specifically unwritten conventions used within projects.</p>
|
|
|
|
<p>Dave mentioned on some of his projects, they have a convention for when to use <code>get</code> or <code>find</code> method prefix names.</p>
|
|
|
|
<p>For example, in a <code>UserRepository</code> class, a method like <code>findUserByEmail()</code> implies that a matching user may not be found.</p>
|
|
|
|
<p>Alternatively, <code>getUserByEmail()</code> implies that you're getting a user and will always be one found and returned.</p>
|
|
|
|
<p>This interested me and I <a href="https://tuhrig.de/find-vs-get">found a blog post by Thomas Uhrig</a> on find vs. get, which I've read since the recording.</p>
|
|
|
|
<p>In the context of the episode, we discussed how conventions like this can be codified and written down and checkable with static analysis tools, but it got me thinking about conventions I've consciously or unconsciously followed, as well as the impact of changing a small word in a method name on its behaviour.</p>
|
|
|
|
<p>What about you?</p>
|
|
|
|
<p>Do you have similar conventions that you follow in your applications?</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|