Skip to content

Commit

Permalink
Fixed formatting in missed rule
Browse files Browse the repository at this point in the history
  • Loading branch information
matt-goldman-ssw committed Nov 5, 2024
1 parent 2da007c commit 88e8a70
Showing 1 changed file with 16 additions and 4 deletions.
20 changes: 16 additions & 4 deletions rules/avoid-generic-names/rule.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,18 +29,30 @@ Generic names like “manager”, "helper", “processor”, “data”, and “
## 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.

:::bad
:::greybox
Imagine you’re writing a class to handle orders in an e-commerce system. You name it `OrderManager`. While this name suggests that it might have something to do with orders, it doesn’t clarify how it interacts with them. Is it creating orders, updating them, processing payments, or all of the above? The generic term “manager” gives us no clear indication.
:::
:::bad
Generic names only tell you what part of the domain or code base a class or method works with, not what it does
:::

:::good
:::greybox
A better name could be `OrderProcessor`, but if the class specifically handles only one aspect — say, sending orders for shipment — a more precise name would be `ShippingOrderHandler` or `OrderShipmentService`. This name directly reflects its purpose, making it immediately clear what the class is responsible for.
:::
:::good
Specific names are better than generic names
:::

:::bad
:::greybox
Let’s say you’re building a system to track medical records, and you create a class called `PatientData`. The name could apply to anything — health information, appointment history, test results. There’s no way to tell what role this class actually plays.
:::
:::bad
The name 'data' could literally mean just about anything
:::

:::good
:::greybox
If the class is responsible for managing a patient’s appointment history, a more accurate name could be `PatientAppointmentHistory`. This name immediately tells us the scope and purpose of the class without relying on catch-all terms.
:::
:::good
A class name for the specific data that it represents is much easier to understand
:::

0 comments on commit 88e8a70

Please sign in to comment.