Do you avoid using your name or your company’s name in client code?
Last updated by Tiago Araújo [SSW] about 1 month ago.See historyWhen building solutions for clients, it’s tempting to include personal or company identifiers in control or component names, like GoldieEntry or SSWButton. However, naming controls after yourself or your company in client projects can create confusion, dilute the client’s branding, and look unprofessional.
For consultants, the goal should be to name components in ways that make sense within the client’s business context.
Why it matters
Names that reflect the client’s brand or domain are clearer and more meaningful for the client’s internal teams and stakeholders. They also reduce the risk of naming conflicts and make it easier for future developers to understand the purpose of a component in context.
Naming a custom entry field GoldieEntry or SSWEntry might make sense in a personal or shared library but is out of place in a client project.
Bad example - Naming client IP after yourself or your company is not cool
Instead, using something like NorthwindStepper is more client-aligned and indicates that this is a customized variation of a standard control.
Good example - Naming client IP with the client's branding is better
Note: This approach is OK to denote a branded version of something, but often it's better to indicate the customization itself in the name. See rule on using meaningful modifiers for custom implementations.
- Do you use clear and meaningful names when coding?
- Do you use verbs for method names?
- Do you use nouns for class names?
- Do you avoid generic names like “manager” or "helper"?
- Do you avoid micro-culture jargon and insider terms?
- Are you consistent with the words you use to represent concepts?
- Do you know when to use technical terms versus domain terms?
- Do you use meaningful modifiers for custom implementations?
- Do you follow naming conventions for tests and test projects?
- Do you use clear and meaningful names when coding?
- Do you use verbs for method names?
- Do you use nouns for class names?
- Do you avoid generic names like “manager” or "helper"?
- Do you avoid micro-culture jargon and insider terms?
- Are you consistent with the words you use to represent concepts?
- Do you know when to use technical terms versus domain terms?
- Do you use meaningful modifiers for custom implementations?
- Do you follow naming conventions for tests and test projects?