Do you avoid generic names like “manager” or "helper"?

Generic names like “manager”, "helper", “processor”, “data”, and “info” are easy to reach for, but they tell us very little about a class or method’s true purpose. These words are catch-alls — they don’t communicate what the code actually does or what entity it represents. Avoiding these vague terms forces us to choose names that reflect a specific role or responsibility.

Why generic names are problematic

Words like "manager" and "processor" imply something that handles various tasks, which can make it tempting to pile unrelated responsibilities into one class. "Helper" makes this worse as it becomes a catch-all for a collection of disorganized functionality. Names like "data" or "info" are similarly ambiguous, as they could apply to nearly anything, from a database connection to a simple string.

Specific names are always preferable, as they make the code easier to understand and prevent code bloat from accumulating unrelated functionality.

Using OrderManager as a class to handle orders in an e-commerce system.

Bad example - While this name suggests that it might have something to do with orders, it doesn’t clarify how it interacts with them. Creating orders? Updating them? Processing payments? All of the above?

Using OrderCreator for specifically creating orders

Using ShippingOrderHandler or OrderShipmentService specifically handles only one aspect of the order - sending for shipment

Good example - This name directly reflects its purpose, making it immediately clear what the class is responsible for

Using UserData for tracking the data for each user account.

Bad example - The name 'data' could mean just about anything

Using UserOrderHistory requires no explanation!

Good example - Immediately tells us the scope and purpose of the class