Don't name objects for what they are used for but for what they represent

Christian Wolf — Mon, 14 Dec 2020 08:30:28 +0000

When reviewing, I often come across code with a, let's say 'dubious' naming.

When looking at the places where this code is integrated in, it becomes clear that the programmer had a concrete necessity and created a tool for it.

Say, at one point we need to keep track how many foos the user entered for a given bar:
Well, I need to count the foos in a bar so I'll just create a FooCounter, it'll have an addBars() method and, of course, a countFoos() method.
Oh, and I only need to count foos of certain bars, so I'll need a hasBarBlurb() method to check if a certain bar is available.

Ready. It all works. Great job done.

Except, you really didn't create a FooCounter. It's more of a BarCollection, isn't it?

I specifically noticed it when I saw the countCurrentFoo(): FooCounter method. Why would a count() method return anything else than an int?

Just rename FooCounter to BarCollection. The methods now make more sense (FooCounter::countFoos(), a counter that counts? BarCollection::countFoos(), yeah, count things in a collection, I've seen that!)

Naming is hard.

It's totally fine starting to name things for what they are used for. Maybe you still have no clear idea where things are going with this new Object, so you gotta start somewhere.

But later on, you should make sure things sound semantically correct and start renaming objects and methods.
Be as close to spoken language as possible.

How to keep events and their listeners organized?

Christian Wolf — Mon, 06 Apr 2020 07:27:50 +0000

Asking for a friend, obviously...

Say, you a have a well kept legacy codebase with a nice framework in place. It's a rather big piece of monolithic glory. It's maintainable. We're well off.

But the concept of triggers, events and listeners gains traction and now events and listeners are popping up left and right. (When all you have is a hammer...)

Now, nobody is demonizing the concept of events and I... err, my friend has used events and listeners quite successfully. But this feeling of being flooded is setting in. You know, when you are not sure if you have seen that exact event message once or twice before. Are we having multiple messages for the same event in different places? Am I listening to the right event?

So I was wondering if you guys have a strategy or style of documentation that would help keep things, at least apparently, organized.

DEV Community: Christian Wolf

Don't name objects for what they are used for but for what they represent

Naming is hard.

How to keep events and their listeners organized?