4 ms·
I too have worked in code bases that have included one or two company name changes in them, and it can really add unnecessary noise to the source. So I think th
by whoisthemachine 4y ago
I too have worked in code bases that have included one or two company name changes in them, and it can really add unnecessary noise to the source. So I think this is actually a counter-argument for using "cutesy" names - swap "cutesy" with "branded" names, and you may see what I mean. This is a basic thing I learned early on and teach others - do your best to not include the name of a product in your codebase, rather focus on the function when trying to name something. It will do you no good if something is called `MyCompanyCart` when it instead could have just been called `Cart`. Most of all, don't include the name of the company in the codebase, especially as variable names, and double especially in data definitions.
- williamcotton 4y agoThe problem with using a brand name in code is that the audience for the brand name is external to the company and subject to change due to conditions in the market. The problem with descriptive names arises when it becomes hard to distinguish between components named “AdServer, “AdRendererServer”, “AdStorageServer”. It’s liking naming a WWII bomber “Fuddy Duffy” and painting Elmer Fudd on the side. It’s a lot easier to find and talk about than K297400!
- pfix 4y agoIsn't that why namespaces were invented? You put those in the namespace `AdServer: { Server, Renderer, Storage }`
- williamcotton 4y agoSure, but what if the AdRendererServer is written in Python and the AdServer is a Rails app? These tend to get turned into acronyms like ARS and AS, and then “ars” and “as”. So a meaningless grunt or an evocative, memorable word?
- whoisthemachine 4y agoNamespacing can exist in more ways than just in code. Surely you could have your server, renderer, and storage components in one repository under the Ads product: Ads/ Server Renderer Storage