The hardest part of programming is not the inner workings of the chosen frameworks and tech.

It's the damn naming.

I will spend hours trying to figure out what to name things for sense and clarity and then a fraction of that time coding it together.

*me, staring out the window*

"Hey dude can you--"

"Ssshhh. I'm naming things."

Reminded me of this

@CrashOverride MultiButtSupporter, haha

@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 it's like you're describing my friend and I... We each follow a different approach... And from time to time, we are assigned to work on the same project 👌

@MrCSharp Good luck with your friendship 🤣

@bittersweet oh.. We definitely gonna need it. Imagine tagging someone like that in your PR... It never gets approved 😆

Take a class with Elodin

@nemanjaglumac ha! I was unaware of those quotes, thanks for sharing. It's also nice having a rant validated. 😀

I used to think the same, then I got a job where they use xcode and objective-c. Trust me, naming stuff is nothing compared to the vomit I have to deal with now 😭

@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.

@Obscura I'll take your word for it, haha. I've heard about objective-c woes, always secondhand though.

@gintko

It's fine when you have an ide, something like a python project would make it so difficult to rename it later

@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.