From f9374a8a82985bb54aa14b8af2e7fcd840c842ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tiago=20Ara=C3=BAjo=20=5BSSW=5D?= Date: Thu, 28 Nov 2024 15:25:52 -0300 Subject: [PATCH] =?UTF-8?q?XS=E2=9C=94=20=E2=97=BE=20Improved=20"avoid-you?= =?UTF-8?q?r-name..."=20rule=20(#9626)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../rule.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/rules/avoid-using-your-name-in-client-code/rule.md b/rules/avoid-using-your-name-in-client-code/rule.md index 3b9a95dbee5..5a3ce305c9b 100644 --- a/rules/avoid-using-your-name-in-client-code/rule.md +++ b/rules/avoid-using-your-name-in-client-code/rule.md @@ -2,7 +2,7 @@ seoDescription: We often use ours or our company name to denote a custom version of something. Unless you're publishing a library, this is never a good idea. type: rule archivedreason: -title: (For consultants) Do you avoid using your or your company’s name in client code? +title: Do you avoid using your name or your company’s name in client code? uri: avoid-using-your-name-in-client-code created: 2024-11-05T00:00:00.0000000Z authors: @@ -25,26 +25,28 @@ related: guid: 7d9eb8d3-4522-40c9-bcbd-b22f48f50edf --- -When 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. +When 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 +## 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. :::greybox -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. +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 -Naming client IP after yourself or your company is not cool +Bad example - Naming client IP after yourself or your company is not cool ::: :::greybox -Instead, using something like `NorthwindStepper` is more client-aligned and indicates that this is a customized variation of a standard control. +Instead, using something like **`NorthwindStepper`** is more client-aligned and indicates that this is a customized variation of a standard control. ::: :::good -Naming client IP with the client's branding is better +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 our rule [Do you use meaningful modifiers for custom implementations?](/use-meaningful-modifiers). +**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](/use-meaningful-modifiers).