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

本文关键字：是否 命名约定 可以使 如果可以 开发 更容易 如果 | 更新日期: 2023-09-27 17:53:11

通常，当你用Javascript或c#开发代码时，你使用CamelCase作为变量，使代码更容易阅读。

然而，我是一个Dynamics CRM 2011开发人员，Dynamics CRM的一个怪癖与字段命名有关。基本上，如果您在Dynamics CRM中创建一个字段，它将以两种不同的格式保存名称:一次是在您输入时使用大小写(例如:new_SocialSecurityNumber)，另一次是完全小写(例如:new_SocialSecurityNumber)。

棘手的部分是，根据使用名称的上下文，您被迫使用特定的版本。例如，在Javascript中，如果你想从表单中获取字段的值，你可以使用小写，但是如果你想使用webservice检索值，你需要使用带大小写的版本(调用本身和返回)。类似地，如果你在c#中开发，取决于你是使用早绑定还是晚绑定，你可以使用带或不带大小写。

现在，在早期绑定中，c#有智能感知，而在后期绑定中，它都是小写的，所以这没什么大不了的，但是Javascript几乎没有任何与CRM相关的智能感知，也没有字段名或webservice相关的值，所以如果你总是把名称用小写，那么处理这些字段会容易得多。

因为需要使用相同字段的正确大小写和小写名称，所以每当我在CRM中创建一个字段时，我都用小写字母书写它。这意味着两个版本的名称是相同的，这使得开发更容易。然而，这并不是c#或Javascript开发中推荐的命名约定。这是一个可以接受的忽略命名约定的理由吗?在这种情况下忽略命名约定的缺点是什么?

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

正如已经指出的，这个问题有点边界，但是让我们来谈谈技术问题:

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而不是new_countryareaid)

.NET Code这也很简单，如果你使用后期绑定，你需要使用逻辑名，如果你使用早期绑定，字段名是自动生成的，代码会看起来更丑，但没有什么戏剧性的

底线:我也用小写字母写字段名，这样模式名就等于逻辑名，但这是我的惯例(以及其他规则)，当我开始定制一个干净的CRM实例时，我会应用它，但当我把手放在一个已经定制的CRM中时，就不总是这样了。

优势vs劣势?这不是一个正确的问题。正确的问题是:

  1. 在你的技术项目文档中描述了命名约定?
  2. 所有的团队成员都知道命名惯例和体罚*，他们需要面对如果他们犯了一个错误?(*我开玩笑的，减薪就够了:D)

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

首先，Guido的回答很好地指出了命名约定差异的不同领域，但我想添加一些没有出现的想法。

约定的唯一目的是使代码更加统一，从而在开发人员之间更易于阅读。所以真正的问题是，"在CRM中使用CamelCase命名模式名会使开发更容易还是更困难?"更具体地说，正如你所说，.net的智能感知使情况差异"不是什么大问题"，所以真正的问题是:

在CRM中使用CamelCase命名模式名称是否使REST调用的开发更容易?

我说，这取决于你拥有的工具。对于。net开发，你自己已经得出了"没什么大不了的"这个结论。我总是使用LinqPad生成我的JavaScript oData调用(也有其他CRM特定的oData助手，但完整版的LinqPad对我来说很好用)。它提供了所需的智能感知，使我不必关心属性是否正确camelcase。

因此，对我来说，不，它不会使开发更容易，因此我将保持惯例

这里有一些其他的可能性可以考虑。

  • VS 2012+有一个非常方便的"word complete"功能，你可以只输入你想要查找的类或属性的大写字母。例如，输入"contact"。FN"会带来"联系。智能意义上的FullName。这是一个非常有用的功能，您可以轻松切换到全小写。(你甚至可以改变Early Bound类的创建，即使模式名不是，也能生成正确的c# camelcase属性，但这需要额外的工作)
  • 即使你所有的自定义实体/属性都是小写的，非自定义的仍然是骆驼大小写。
  • 可读性在所有小写环境中受到阻碍。例如statusstarting vs statusstarting vs statusstarting。恶心…

你应该问自己的问题是:这个名字对于六个月后维护这个代码的人来说是否容易理解

如果你预见到维护你正在编写的JavaScript代码的人将是c#开发人员，我认为完全可以跳过惯例而使用c#风格。

约定是用来帮助人们理解不是他们自己编写的代码的，因为这些代码将以他们熟悉的风格编写，所以如果约定在这件事上没有帮助，那么遵循约定就没有意义了。

相关文章：