---
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"
---
[

![Tari Ibaba](https://miro.medium.com/v2/resize:fill:88:88/1*hrkjW77qwMoev9kLXYZg5w.png)

](https://medium.com/@tariibaba?source=post_page---byline--077cf44e972b--------------------------------)

[

![Coding Beauty](https://miro.medium.com/v2/resize:fill:48:48/1*ViyWUoh4zqx294no1eENxw.png)

](https://medium.com/coding-beauty?source=post_page---byline--077cf44e972b--------------------------------)

![](https://miro.medium.com/v2/resize:fit:700/1*f1tKna6bzPXw_tFhKgyzJQ.png)

I was coding and stumbled upon something really disappointing the other day.

Do you see it? 👇

![](https://miro.medium.com/v2/resize:fit:700/0*pmjV4iNa3VGiiVyd.png)

Let’s zoom in a bit more:

This line:

![](https://miro.medium.com/v2/resize:fit:700/0*GcpguHAAHvH7IVYl.png)

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:

![](https://miro.medium.com/v2/resize:fit:700/1*AWABHQ9Gd4P1JfFsFhP_Vw.png)

Derived states — what getters are meant for:

![](https://miro.medium.com/v2/resize:fit:700/1*5yuHUzOTjaZFSz5xw9Brig.png)

But the `status` property was returning a Dart `Future` -- JavaScript's `Promise` equivalent:

❌Before:

![](https://miro.medium.com/v2/resize:fit:700/1*tJBCnpjKBlNVHqPl0ecA0A.png)

It would have been so much better to use a method:

✅ After:

![](https://miro.medium.com/v2/resize:fit:700/1*Ze0EpXUQ7rvxA3nulolKyQ.png)

And now `async/await` can make things even more intuitive:

![](https://miro.medium.com/v2/resize:fit:700/1*7Jeaf91hcrf8k07Sl-CdyA.png)

But guess what happens when you try `async/await` with properties?

![](https://miro.medium.com/v2/resize:fit:700/0*edX2V83w7j2cLAix.png)

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:

![](https://miro.medium.com/v2/resize:fit:700/1*wyceIwJF4Xh-EOEKw5CEJw.png)

✅ After:

Let them know that the action is expensive enough to deserve caching or variable assignment:

![](https://miro.medium.com/v2/resize:fit:700/1*ipKw5sSjHKJqYfywMgwVwQ.png)

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?

![](https://miro.medium.com/v2/resize:fit:700/1*VNCORz5DHhxsD6Vb1C5BDA.png)

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.

![](https://miro.medium.com/v2/resize:fit:700/1*inyAYftsfI5Iuwzu9PatAA.png)

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.

![](https://miro.medium.com/v2/resize:fit:700/1*hDM-y6OtRs3eSWoM5Wg1dw.png)

Nouns for entities: variables, properties, classes, objects, and more.

Not this:

![](https://miro.medium.com/v2/resize:fit:700/1*hZ0OuKdG3ppwK_oMOBoS4Q.png)

But this:

![](https://miro.medium.com/v2/resize:fit:700/1*LOwexu-HkZKIG096SOKeSA.png)

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.