【问题标题】:.Net naming conventions vs W3C specifications.Net 命名约定与 W3C 规范
【发布时间】:2010-09-23 13:47:10
【问题描述】:

在使用 .Net 实现部分 W3C HTML5 规范时,我很难解决命名约定冲突。

问题是我喜欢遵循标准的 .Net 命名约定,它使用 UpperCamelCasing,但 W3C 规范表明命名约定应该使用 lowerCamelCasing。

我应该偏离规范以编写对 .Net 社区友好且熟悉的代码,还是应该使用 W3C 推荐的约定以尽可能地遵守规范,即使这样做会让我的 Code.notVeryPretty()?

编辑

例子:

W3C 定义了一个接口IDOMImplementation 和一个成员hasFeature()。如果我在没有 W3C 规范指导实现的情况下编写 .Net 代码,这些代码将被命名为 IDomImplementationHasFeature(),但 W3C 定义了上述命名约定。

编辑

要以完全不同的方式提出这个问题,在使用 .Net 实现规范时偏离 W3C 推荐的大小写约定是否有任何不利之处?

【问题讨论】:

  • 我不知道 W3C 有 .NET 编码标准。
  • .NET 和 W3C 没有任何关系...
  • W3C 没有 .Net 编码标准。微软(以及整个 .Net 社区)确实如此。
  • W3C 是不可信任的。任何与 W3C 相关的人都是笑话。

标签: .net naming-conventions


【解决方案1】:

UpperCamelCasing 用于.NET 代码,将lowerCamelCasing 用于您的HTML/CSS/Javascript/其他W3C 内容。

在什么情况下您会使用 W3C 推荐的命名约定来编写 .NET 代码?

编辑:

既然您已经明确了您的意思,我想说,由于您的代码将在 .NET 中使用,因此您应该坚持使用 .NET 约定,即使在实现由W3C。

【讨论】:

  • 换句话说,坚持定义它的纯 W3C 规范并在其他地方使用正常的 .Net 命名约定?有关我所说的示例,请参阅上面的编辑。
  • 是的。让 JavaScript 看起来应该和 C# 看起来应该一样。它们确实有不同的约定,这使得习惯于两者的人更容易遵循代码。
  • JavaScript 是另一回事,可能无论如何都会被包装,以确保只有适当的功能暴露给脚本引擎。
猜你喜欢
  • 1970-01-01
  • 2014-09-03
  • 2011-07-23
  • 1970-01-01
  • 2015-03-30
  • 2012-11-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多