In order to vote, comment or post rants, you need to confirm your email address.
You should have received a welcome email with a confirm link when you signed up. If you can't find the email, click the button below.

@CrashOverride Haha but there's not even consensus among OOP fans: Some swear by patterning everything and naming it all according to patterning conventions: manager controller helper handler converter validator router dispatcher observer listener etc

Then there are those who consider all classes ending in er/or to be filthy, because they don't describe the domain properly, and too often end up being muddied with tasks outside their original responsibility.

@bittersweet you've described how I feel pretty much. There are so many ways of naming things, and to add to my uncertainty I've largely been working by myself for the last three years. As much as I hate cubicle chats, it's nice being able to bounce ideas off of people. Honestly though, working alone also has tremendous advantages too. It ain't all bad.

@harshil912 true. I don't like settling for sub-par names, because even with the rationalization that we can change it later, in my experience it rarely happens. It ends up bleeding into many other areas (like separate processes, database names/tables/columns, documentation) where it's not just a one-click rename. Then you're stuck with it because of effort involved and where it falls in priority. It takes extra time to start with great naming, but it saves time/headaches overall.

The thing that triggers me most right now is what I call ‘service culture’, where everything is a SomethingService.... I hate it. I have genuinely seen classes in my codebase that end with ...ValidationService.
ITS A VALIDATOR! CALL IT A VALIDATOR!!
Or CalculationService.... its a calculator guys.
So Im now on a mission to destroy all services. If it doesnt serve me something, its not a service.

@duckWit Yup. I can relate. I've at times made commits promising my inner self to refactor the names to something more appropriate after a few days before the pr is sent for approval just so that the build could be testing on staging.
8/10 times someone has suggested better names on commits than the pr's.
It's a good thing to start off with naming right, than procastinate later.