thpeetz-notes/Clippings/Stop Doing This Or Nobody Will Understand Your Code.md

title, source, author, published, created, description, tags

title	source	author	published	created	description	tags
Stop Doing This Or Nobody Will Understand Your Code	https://medium.com/coding-beauty/methods-vs-properties-077cf44e972b	Tari Ibaba	2024-10-16	2024-10-29	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…	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.