如果它使开发更容易，忽略命名约定是否可以接受？

Question

通常，当您使用Javascript或C＃开发代码时，可以使用CamelCase作为变量，以使代码更易于阅读。

但是，我是Dynamics CRM 2011开发人员，而Dynamics CRM的一个怪癖与字段命名有关。基本上，如果您在Dynamics CRM中创建一个字段，它会以两种不同的格式保存名称：输入时使用外壳一次（例如：new_SocialSecurityNumber），一次使用完整的小写（例如：new_socialsecuritynumber）。

棘手的部分是，根据上下文使用的名称，您将被迫使用特定版本。例如，在Javascript中，如果要从表单中获取字段的值，则使用小写，但如果要使用Web服务检索值，则需要使用带有大小写的版本（两者都用于调用本身和返回）。同样，如果你在C＃中进行开发，取决于你是使用早期绑定还是晚期绑定，你可以使用或不使用套管。

现在，使用Early绑定，C＃具有Intellisense，而使用Late绑定，它全部为小写，因此这并不是什么大不了的事，但Javascript几乎没有任何与CRM相关的Intellisense，并且没有字段名称或与Web服务相关的值，因此如果您始终将名称设置为小写，则使用这些字段会更容易。

由于需要同时使用同一字段的正确套件和小写字母，每当我在CRM中创建字段时，我都会以全小写形式编写字段。这意味着名称的两个版本都相同，这使得开发更容易。但是，这不是C＃或Javascript中开发的推荐命名约定。这是否是忽略命名约定的可接受理由？在这种情况下忽略命名约定有什么缺点？

Answer 1

正如已经指出的那样，这个问题有点边缘，但是让我们谈技术：

Dynamics CRM使用Schema Name和Logical Name存储字段名称。

Schema Name是您在创建字段时输入的字段，它区分大小写（这意味着new_AccountId与new_accountid不同。）

Logical Name始终是Schema Name的小写字母，因此如果架构名称为new_ContactId，则逻辑名称为new_contactid

作为Dynamics CRM Developer，您需要在以下情况下处理字段名称：

1. Xrm JavaScript对象模型
2. 调用REST webservices
3. .NET代码（插件，自定义工作流活动，自定义代码，...）

Xrm JavaScript对象模型使用逻辑名称，非常简单（隐藏字段，设置值，... Xrm.Page.getAttribute("logicalname").getValue();）

REST调用：使用Schema Name，没有其他选择，这意味着您可以用小写编写字段名称，因此模式名称等于逻辑名称，但是OOB字段使用大写字母，更重要的是，您不是所有CRM环境的定制程序（这意味着很容易最终在已经定制的CRM中工作，其中字段名称为new_CountryAreaid或new_countryAreaId而不是{{1 }}）

new_countryareaid这也很容易，如果你使用后期限制你需要使用逻辑名称，如果你使用早期绑定自动生成字段名称，代码看起来会更丑，但没什么戏剧性的

底线：我还用小写编写字段名称，因此模式名称等于逻辑名称，但这是我的约定（以及其他规则），当我开始自定义干净的CRM实例时，我应用它，但是并不总是当我把手放在已经定制的CRM中时。

与Disadvantes的优势？这不是正确的问题。正确的问题是：

1. 在技术项目文档中描述了命名约定？
2. 所有团队成员都知道他们犯错时需要面对的命名惯例和体罚*？ （*我在开玩笑，减薪就足够了：D）

Answer 2

如果它使开发更容易，忽略命名约定是否可以接受？当然。

首先，Guido的答案很好地回答了在命名惯例的差异很重要的不同领域，但我想添加一些不存在的想法。

创建约定的唯一目的是使代码更加统一，因此，开发人员之间的可读性更高。所以真正的问题是，“使用CamelCase命名CRM中的模式名称会使开发变得更容易还是更难？”更具体地说，正如你所说，.net的intellisense使得案例差异“不是什么大问题”，所以真正的，真实的问题是：

  

在CRM中命名架构名称时使用CamelCase是否可以在进行REST调用开发时更轻松？

我说，这取决于你拥有的工具。你已经通过.net开发的“不是很大的事”来得出这个结论。我总是使用LinqPad生成我的JavaScript oData调用（还有其他CRM特定的OData助手，但LinqPad的完整版本对我很有用）。如果属性是正确的CamelCased，它提供了让我不关心的智能感知。

因此，对我而言，不，它不会使开发变得更容易，因此我会遵守惯例。

以下是其他一些可以考虑的方法。

• VS 2012+有一个非常方便的“单词完整”功能，您只需键入您尝试查找的类或属性的大写字母。例如输入“contact.FN”会在intellisense中显示“contact.FullName”。一个非常有用的功能，您将松开切换到所有小写。 （你甚至可以将Early Bound类创建更改为仍然生成正确的C＃CamelCased属性，即使模式名称不是，但它还需要额外的工作）
• 即使您的所有自定义实体/属性都是小写的，非自定义实体/属性仍然是CamelCased。
• 可读性在所有小写环境中都受到阻碍。例如statusstarting vs statUsStarting vs statusStarting vs statusStarTing。呸...

Answer 3

您应该问自己的问题是：此名称将在六个月后维护此代码的人员易于理解

如果你预见到你正在编写的一些JavaScript代码的人将是一个C＃开发人员，我发现完全可以跳过这些约定并使用C＃样式。

有些公约可以帮助人们理解不是由他们编写的代码，因为它们会以他们熟悉的方式编写，所以如果他们在这方面没有帮助，那么下面的约定就没有意义了。