给房产最好的命名?

发布于 2024-09-02 11:58:29 字数 104 浏览 2 评论 0原文

您会选择以下三个选项中的哪一个作为 C# 中的属性名称,为什么?

  1. 今年迄今工资
  2. YTDWages
  3. YTDWages

Which of the following three options would you choose for a property name in C#, and why?

  1. YearToDateWages
  2. YTDWages
  3. YtdWages

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(10

誰認得朕 2024-09-09 11:58:29

我会选择 1。我不想缩写任何东西,除非它是一个非常常见的缩写词,拼写出来会很荒谬。像“HyperTextTransferProtocolRequest”这样的东西拼写出来会很荒谬,因此可以安全地将其缩写为“HttpRequest”。这有点主观,但当有疑问时,我倾向于不缩写。

如果您决定选择 2 或 3,根据“框架设计指南”的建议,我可能会投票给 3。它基本上表示,对于 3 个或更多字母长的首字母缩略词,您应该将第一个字母大写,其余字母小写。对于 2 个字母的首字母缩略词来说有点含糊...有些人喜欢将所有字母大写,例如“ID”,而有些人则喜欢使用“Id”。该指南实际上是将 2 个字母缩写词的所有字母大写,但这与 3 个以上字母缩写词的指南相矛盾,因此人们同时采用这两种方法。

I would go with 1. I prefer not to abbreviate anything, unless it's a super-common acronym that would be ridiculous to spell out. Something like "HyperTextTransferProtocolRequest" would be ridiculous to spell out, so it's safe to abbreviate that as "HttpRequest." It's a little subjective, but when in doubt, I tend to not abbreviate.

If you decide to go with 2 or 3, I'd probably vote for 3, based on the recommendations from the "Framework Design Guidelines." It basically says that for acronyms that are 3 or more letters long, you should capitalize the first letter and lower-case the rest. It's a little ambiguous on 2-letter acronyms... Some people prefer to capitalize all letters like "ID" and some prefer to go with "Id". The guideline is to actually capitalize all letters of a 2-letter acronym, but that kind of contradicts with the guideline for 3+ letter acronyms, so people do it both ways.

顾忌 2024-09-09 11:58:29

我会使用 YearToDateWages,因为如果列表中没有它,我就不知道您在说什么。

另请参阅 MSDN 上的一般命名准则

一般来说,您不应使用缩写词或首字母缩略词。这些会让你的名字不那么可读。同样,很难知道何时可以安全地假设缩写词被广泛认可。

有关缩写词的大写规则,请参阅大写约定。< /p>

请勿使用缩写或缩写作为标识符名称的一部分。

例如,使用 OnButtonClick 而不是 OnBtnClick。

不要使用任何未被广泛接受的缩写词,仅在必要时才使用。

强调原文。

I would use YearToDateWages, because without that being in the list I wouldn't know what you were talking about.

See also the general naming guidelines on MSDN:

In general, you should not use abbreviations or acronyms. These make your names less readable. Similarly, it is difficult to know when it is safe to assume that an acronym is widely recognized.

For capitalization rules for abbreviations, see Capitalization Conventions.

Do not use abbreviations or contractions as parts of identifier names.

For example, use OnButtonClick rather than OnBtnClick.

Do not use any acronyms that are not widely accepted, and then only when necessary.

Emphasis in original.

风轻花落早 2024-09-09 11:58:29
bool ShouldIUseAbbreviate(string abbreviate_)
{
  foreach (var peer in myPeers)
  {
    if (!peer.CanGetTheMeaningWithinOneSecond(abbreviate_))
    {
      return false;
    }
  }

  return true;
}
bool ShouldIUseAbbreviate(string abbreviate_)
{
  foreach (var peer in myPeers)
  {
    if (!peer.CanGetTheMeaningWithinOneSecond(abbreviate_))
    {
      return false;
    }
  }

  return true;
}
残龙傲雪 2024-09-09 11:58:29

我认为第一个是最好的,因为它是自我描述的。

I think the first one is best because it is self descriptive.

勿忘初心 2024-09-09 11:58:29

微软建议命名约定排除 #2

任何带有 > 的内容。 2 个缩写字母应该是 Xxx 而不是 XXX,

但 2 个应该是 XX

我喜欢少打字,所以我会选择 YtdWages

Microsoft suggested naming convention rule out #2

anything with > 2 acronym letters should be Xxx not XXX

but 2 should be XX

I like less typing so I would go with YtdWages

遇见了你 2024-09-09 11:58:29

这取决于。

如果您正在创建一个可供外部使用的库,请参考 .NET Framework 设计指南 说#1 是首选。

如果它是内部应用程序/库,那么我建议使用与您的团队开发标准一致的格式。

It depends.

If you are making a library that will see external use, the .NET Framework Design Guidelines say that #1 is preferred.

If it's an internal application/library, then I recommend using the format that is consistent with your teams development standard.

〗斷ホ乔殘χμё〖 2024-09-09 11:58:29

我会选择全名而不是缩写词。它更具描述性,虽然“YTD”对某些人来说可能是显而易见的,但可能并非对所有人来说都是如此。 YearToDate 不算太长,含义也很明确。

I would opt for the full name rather than one featuring an acronym. It is more descriptive, and while "YTD" may be obvious to some, it might not be to everyone. YearToDate is not excessively long and the meaning is clear.

心病无药医 2024-09-09 11:58:29

您有理由不使用第一个吗?

这不仅是为了别人,也是为了别人。如果两年后您必须更改自己的代码中的某些内容,好的描述性名称会对您有所帮助。

Is there a reason why you would not use the first one?

It is not only for others; if you have to change something in your own code 2 years later, good, descriptive names will help you.

℉絮湮 2024-09-09 11:58:29

.Net 框架似乎主要遵循#1。所以我会坚持下去。应避免使用缩写,除非在课堂上非常常见。当然,对于本地(函数)变量来说,这不那么严格,我想说缩写和短名称更合适,以使代码更小、更简洁。

好的缩写的例子有 XML 和 HTTP。谁认真去写

string x=myobject.HyperTextMarkupLanguageOutput;

The .Net framework seems to follow mostly #1. So I would stick with it. Abbreviations should be avoided except where extremely commonly known at the class level. Of course for local(function) variables this is much less strict and I would say that abbreviations and short names are much more appropriate so as to make the code smaller and more concise.

Examples of good abbreviations are XML and HTTP. Who is seriously going to write

string x=myobject.HyperTextMarkupLanguageOutput;
明媚如初 2024-09-09 11:58:29

我也投票给1号。

很少有时候您不想要一个描述性的名称。
Visual Studio 将帮助您处理长名称。

半题外话注:
如果你找不到合适的名字......也许计划的用途毕竟不是那么清楚;)

I vote for number 1 as well.

There will be very few times when you do NOT want a descriptive name.
Visual Studio will assist you with the long names.

Semi off topic note:
If you cant find a suitable name... perhaps the planned usage is not that clear after all ;)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文