Call is a Terrible Method Name

You see it all the time…in Rails codebases – developers frequently using the method name call to invoke an action.

MemberMigration.new(member).call

Technically, it works. Visually, it is clean. But semantically, call is a terrible method name. It strips away domain logic.

It Hides Domain Logic

Let’s rename it:

MemberMigration.new(member).migrate_orders

Now the method name carries information. It tells us we’re migrating orders for a member. More importantly, a developer doesn’t have to dig into the method to understand what it is supposed to do.

call also flattens the vocabulary of an application. Consider:

PaymentCapture.new(order).call
FraudCheck.new(order).call
FulfillmentRequest.new(order).call

These are three completely different operations, but from the calling code they all look the same. Compare that with:

PaymentCapture.new(order).capture_payment
FraudCheck.new(order).screen_for_fraud
FulfillmentRequest.new(order).request_fulfillment

Now the code starts describing the business process.

The same loss of context shows up in tests. Compare these RSpec blocks:

describe "#call" do

with:

describe "#migrate_orders" do

The second tells me what behavior is being tested before I’ve read a single example. #call forces me to inspect the class or the tests to figure out what the method actually does.

That’s the recurring cost of call: every time someone encounters it, they need additional context to understand it.

Good method names are documentation, search anchors, and context you don’t have to reconstruct later.

It Makes Codebases Unsearchable

Good code is easy to navigate. If you search a large codebase for .call, you will end up with hundreds of unrelated results.

Searching for migrate_orders will return a significantly smaller and more useful set of results.

It Ruins Stack Traces

Stack traces are maps, and maps need to provide clear direction. Consider a failure hidden behind generic names:

order_processor.rb:87:in `call'
member_migration.rb:42:in `call'
supplier_service.rb:116:in `call'

Now look at a stack trace using explicit verbs:

order_processor.rb:87:in `submit_to_supplier'
member_migration.rb:42:in `migrate_orders'
supplier_service.rb:116:in `place_order'

The first tells me where the application failed.

The second starts telling me what the application was doing when it failed.

submit_to_supplier tells me we’re talking to a supplier. It might be an API call, so checking the supplier’s service status is an obvious next step.

call tells you that something is being invoked. A good method name tells you what.

Parting Thoughts

Naming is one of the cheapest ways to make code easier to understand. In most circumstances, a verb-noun combination is better.