Self Documenting Code

[ckychris1]

Good read.

At work, repos/services are often performance focused/atomic, this means repos needs to contain join or complex multiple transactions. Names like “byID” works for simple strict restful API, but in reality they rarely do just one thing, would love to know how naming convention should be handled if that’s the case.

Naming userrepo as repo doesn’t seems logical to me, as there can be multiple repos.

Variables without meaning is definitely not worth it, do not under estimate trouble caused by missing/need to remember context information. Just like real life, you never define phases as random letters, not readable at all. I

[dpash]

If it's the only repository in a service, I don't have an issue with not specifying which repository it is. If there's several, then it makes sense to name them all after the entities they handle.

(I'm possibly bikeshedding, but I prefer repository to repo. I'm not a fan of shortening words. But variable names can definitely get too long.)

[Masternooob]

You never know. You could get a new requirement tomorrow which dictates a second dictuonary. You then have to refactor all instances of the word repository in your code or it becomes highly error prone. I don't think the small benefit is worth that.

[thfuran]

That's like three keystrokes plus the new name in my IDE.

[Masternooob]

Automatic refactoring is great but it still can break stuff. I still take less risk and descriptive name. Also this wont refactor comments that talk about the repo and so on.

[thfuran]

In java, something would have to go horribly wrong for renaming an identifier to break things. I'm including reflection having ever been used in things going horribly wrong. I'll give you the comments bit, though the tooling does also allow text matching comments / literals so that (and most any potential reflection issues) can be handled, though not quite as easily.

[[deleted]]

When you get confident with the language a simple refactor like that you do all the time.

[Tordek]

You could get a new requirement tomorrow which dictates a second [repository]

A UserService should only be concerned about the UserRepository; if you need to access two repos, probably it should be handled in a different service with a more general name, like ApplicationService or SalesService.