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: {  }