I've been struggling with naming things in my projects, especially as they expand. When I'm working on mock projects from tutorials, naming is straightforward. But in real production environments, it gets complicated as the project scales. Like, I often create formatters to handle different variations of data, such as an order formatter that might need to adjust depending on user roles or particular fields (like product details). This leads to a mess of formatters and functions with names that don't always make sense, and it becomes impossible to keep track of everything.
I also encounter issues naming functions, classes, and their methods. For example, I might have functions like `update_user_with_role` and `update_user_normal`, but these names get unwieldy. I've read that complicated naming can indicate a violation of the Single Responsibility Principle, but I'm not sure how to reorganize my code.
I've tried using temporary placeholder names to keep moving forward, but that just leads to messy code and confusion later on. I'd appreciate any tips or resources for how to establish a clearer naming scheme or guidelines, especially for complex coding scenarios. Any thoughts on common naming patterns or rules I can follow would be super helpful!
3 Answers
Always remember to focus on the actual action that the method is performing. In your example of tax calculation, you might be overcomplicating the name. If it’s just calculating tax based on items, stick with `calculate_tax`. The internal logic can handle various cases, and the name itself should remain clean and self-explanatory.
I'd say align your naming with the domain of your project. Using concepts like 'bounded contexts' can help mitigate naming confusion. By establishing the specific roles and processes in your business domain, you can clarify what each component does without lengthy method names. Look up Martin Fowler's bounded context concept for a deeper understanding. This way, your naming conventions become more intuitive and context-driven.
Naming things can definitely get tricky, especially in larger codebases or when multiple team members are involved. A good start is to establish naming schemas for consistency. For instance, if you name all your formatters in a way that reflects their purpose, like `OrderFormatterBasic`, `OrderFormatterForAdmin`, and so on, it can really help with clarity.
Also, instead of too many specific functions, consider using a service-oriented approach. For instance, instead of defining a bunch of update functions, why not create a `UserService` and use it to handle updates, passing the necessary data as parameters? This separation could enhance maintainability too. Think about breaking things down into smaller, modular services that each manage a specific responsibility.
I see a point about using services. But sometimes we need specific data attributes based on the user role, like an IP check for admins. How do you handle that without bogging down everything with excess data?
That naming scheme is solid! But do you think it's better to have methods like `orderFormatter.basic(order)` instead of separate functions? I get that it can tidy up the code a lot!