What are the pros and cons of naming namespaces & classes after the name of a product?
Posted by sweetnsourgrapes@reddit | ExperiencedDevs | View on Reddit | 20 comments
You're building a new product (e.g. a web app) which the company calls "Scobble" (just made that up, amazingly it's not a thing - yet).
How wise, or otherwise, is it to start using the product name in your solution structure? For example; Scobble.Services.Email, Scobble.AppConfig, ScobbleDbConnectionString and that sort of thing?
What approach do you take when writing code for a specific product, while in the back of your mind you have this niggling suspicion they are going to change the name of it in a few months? 😅
BoBoBearDev@reddit
Name it after the company.
Arkarant@reddit
Companies can have more than 1 product tho
Natty-6996@reddit
Testiculus Rift an VR for your Gonads!
socialist-viking@reddit
Every time I name something after the project title, it goes south. Say they call it the "Employee Indexing Program" so I name the codebase "emp_index". As soon as I do, it's changed to "The People Power Hub" and now I'm stuck. Worse still, every client I have at one organization ends up calling their project something ending in "hub" - "The People Power Hub", "The Employee Intelligence Hub", "The Space Laser Hub". Then, I get baffling emails telling me that some rando has found a bug in "The Hub." Which hub?
So, I just make up cool names like "SpaceLazer" for my projects.
My corollary problem though, because I do so much training software, is "class". There are classes everywhere, but naming them "class" has some obvious drawbacks.
IssueConnect7471@reddit
Keep product names out of namespaces unless you plan to trademark them for life. I’ve seen three rebrands in five years and each one burned a sprint just for search-replace, test fixes, and package republishing. Instead, anchor the namespace to something stable: the company domain (Acme.Finance...) or the bounded context (Billing, Auth, Catalog). If you need to separate multiple products in the same repo, give them neutral codenames (e.g., Phoenix, Atlas) that never leave engineering; marketing can change labels while your code stays still. Build config settings-connection strings, feature flags, env variables-so they sit outside the namespace and can be swapped in CI. When legal finally flips the logo, your diff is basically a README update. Azure DevOps and SwaggerHub handle the pipeline and docs, but DreamFactory’s auto-generated API layer saved us when we swapped databases without touching the namespace tree. Sticking to domain-based names keeps you moving when branding storms roll through.
FormerKarmaKing@reddit
Con: product will likely fail and question will be irrelevant.
Pro: see above.
Nater5000@reddit
My policy is to (a) consider the hierarchy, (b) be cognizant of uniqueness, and (c) minimize length.
So, for example, if you have a web app named Scobble which is primarily deployed as a Kubernetes cluster in AWS (where multiple instances can exist in the same account), then it's imperative that you enforce uniqueness in high-level names (e.g., EKS clusters, RDS clusters, S3 buckets, etc.) to avoid naming conflicts while also making it clear what the purpose of those resources are (e.g., an S3 bucket dedicated to a Scobble deployment should probably have "scobble" somewhere in the name). Furthermore, the naming scheme, itself, should be consistent across the board, e.g., buckets named "scobble-storage-", etc.
Within the app, there should (usually) be enough isolation and context that incorporating "scobble" or the environment name isn't needed. Like, within the Scobble app, it is redundant to have variable names like "ScobbleDbConnectionString" if there is only ever one DB connection string to deal with, so you'd be better of with just "DbConnectionString". I'd even go a step further to say that if there are no other connection strings to consider, then you should just call it "ConnectionString" (although a little forward thinking is warranted here). If there are multiple connection strings at play, they should all be related to Scobble anyways, so whatever prefix/suffix you use to identify them should be more specific.
Of course, much of this is nebulous and will evolve over time. The main consideration, for me, is ensuring uniqueness when required and making sure I can list/sort/query/etc. resources in a sane way, which is why I'd use name schemes like "scobble--" so that, when I list these resources, I can quickly see I have X scobble resources, of which there are Y different groups of resources based on purpose, and for each purpose, there are Z different envs, etc. But this may be a bigger consideration for cloud engineers than for other contexts, etc.
dacydergoth@reddit
S3 names at globally visible; just use a guid for the name and tag it correctly
Heavy_Thought_2966@reddit
There will always been drift over time and you can’t solve that perfectly. My rule of thumb is: name things for what they do, and avoid business unit names like team or product groups.
Business unit names tend to shift the most over time or they get reorged and reshuffled so using those is a losing battle. Product names can change, but often knowing the history of a product can inform how it works so that history can be useful to know.
trwolfe13@reddit
My company renames everything every few months, right down to core business entities. You can date parts of our codebase to the nearest quarter by what things are called.
bbqroast@reddit
I'd also argue product names can sometimes be better than "what it does".
In most big companies, you'll end up with several products that do different things but the shortened "what it does" name ends up being the same or very similar. It can actually be less confusing to have unrelated fun names for these services.
lurkin_arounnd@reddit
You also don't have to really pick one. You can combine them both.
For example: product-name-hive-metastore
aRightQuant@reddit
Great advice
The only thing to add is using a specific prefix when packaging to avoid package manager injection attacks
tehfrod@reddit
That's why projects being developed pre-go-to-market typically use code names.
Project code names can stay the same through many generations of product name changes, and vice versa: if FooMatic v4 is being built on a new code base from FooMatic v3, the v4 codebase can have a different project name from the v3 codebase.
Xia_Nightshade@reddit
Holy god damn dude you did it
https://www.npmjs.com/search?q=Scobble
0 results. Haven’t read the rest of your post, but consider me impressed!
DeterminedQuokka@reddit
So be prepared for when they rename it in 2 years to explain it’s not worth the time to rename it in the codebase that literally no one looks at. I have trained our devs to use alternative names for 2 of our products because if they say the original name in the codebase I get a ticket that says “remove all mentions of X from the codebase”. So now the codebase says the old name engineers say a generic name.
wipecraft@reddit
Be prepared to use right click - refactor - rename in 2 years. It’s gonna be tough /s
BertRenolds@reddit
Try not to use the name at all. Why would you anyways?
Also sed is a thing
tyler_church@reddit
Only use the name when necessary "DbConnectionString" not "ScobbleDbConnectionString".
Small pieces of an app you can be named after what they do ("ReportFormatter") rather than how they're branded ("ReportTron2000Formatter").
But if you need it for a toplevel package/module name or something like that... You have to call it something. Might as well use Scobble. You can bite the bullet and rename it later, or you can just internalize the cool codename! It'll make onboarding slightly harder but all the old hands will get it.
So_Rusted@reddit
It is fine. Things have to be named. You dont have to necessarily change them later