146 lines
4.3 KiB
Markdown
146 lines
4.3 KiB
Markdown
---
|
||
title: "Stop Doing This Or Nobody Will Understand Your Code"
|
||
source: "https://medium.com/coding-beauty/methods-vs-properties-077cf44e972b"
|
||
author:
|
||
- "[[Tari Ibaba]]"
|
||
published: 2024-10-16
|
||
created: 2024-10-29
|
||
description: "This rule doesn’t just apply to async tasks, it applies to any long-running action, synchronous or not: It doesn’t just modify the backing _fullness field -- it changes multiple other fields. This…"
|
||
tags:
|
||
- "clippings"
|
||
---
|
||
[
|
||
|
||
|
||
|
||
](https://medium.com/@tariibaba?source=post_page---byline--077cf44e972b--------------------------------)
|
||
|
||
[
|
||
|
||
|
||
|
||
](https://medium.com/coding-beauty?source=post_page---byline--077cf44e972b--------------------------------)
|
||
|
||
|
||
|
||
I was coding and stumbled upon something really disappointing the other day.
|
||
|
||
Do you see it? 👇
|
||
|
||
|
||
|
||
Let’s zoom in a bit more:
|
||
|
||
This line:
|
||
|
||
|
||
|
||
Please don’t do this in any language.
|
||
|
||
Don’t `await` properties.
|
||
|
||
You’re destroying your code readability and ruining the whole concept of OOP.
|
||
|
||
Properties are features not actions.
|
||
|
||
They don’t **do** like methods. They are.
|
||
|
||
They are data holders representing states of an object.
|
||
|
||
Simple states:
|
||
|
||
|
||
|
||
Derived states — what getters are meant for:
|
||
|
||
|
||
|
||
But the `status` property was returning a Dart `Future` -- JavaScript's `Promise` equivalent:
|
||
|
||
❌Before:
|
||
|
||
|
||
|
||
It would have been so much better to use a method:
|
||
|
||
✅ After:
|
||
|
||
|
||
|
||
And now `async/await` can make things even more intuitive:
|
||
|
||
|
||
|
||
But guess what happens when you try `async/await` with properties?
|
||
|
||
|
||
|
||
Exactly. It’s a **property**.
|
||
|
||
This rule doesn’t just apply to `async` tasks, it applies to any long-running action, synchronous or not:
|
||
|
||
❌ Before:
|
||
|
||
|
||
|
||
✅ After:
|
||
|
||
Let them know that the action is expensive enough to deserve caching or variable assignment:
|
||
|
||
|
||
|
||
But sometimes it still doesn’t deserve to be a property with this.
|
||
|
||
Check this out — do you see the issue with the `level` setter property?
|
||
|
||
|
||
|
||
It doesn’t just modify the backing `_fullness` field -- it changes multiple other fields. This doesn't make sense as a property, as data.
|
||
|
||
It’s affecting so much aside from itself.
|
||
|
||
**It has side-effects.**
|
||
|
||
Setting this property multiple times modifies the object differently each time.
|
||
|
||
|
||
|
||
So even though it doesn’t do much, it still needs to be a method.
|
||
|
||
## Name them right
|
||
|
||
Natural code. Coding like natural language.
|
||
|
||
So always name the properties with nouns like we’ve been doing here.
|
||
|
||
But you see what we did when it was time to make it a property?
|
||
|
||
We made it a verb. Cause now it’s an action that does something.
|
||
|
||
|
||
|
||
Nouns for entities: variables, properties, classes, objects, and more.
|
||
|
||
Not this:
|
||
|
||
|
||
|
||
But this:
|
||
|
||
|
||
|
||
Verbs for actions: functions and object methods.
|
||
|
||
## Key points: when to use a method vs a property?
|
||
|
||
Use a property when:
|
||
|
||
- The action modifies or returns only the backing field.
|
||
- The action is simple and inexpensive.
|
||
|
||
Use a method when:
|
||
|
||
- The action modifies multiple fields.
|
||
- The action is async or expensive.
|
||
|
||
All for clean, readable, intuitive code. |