C# 格式化约定

发布于 2024-08-06 10:00:53 字数 631 浏览 7 评论 0原文

在我读过的一本书中，他们使用大写字母来表示公共方法和属性。我知道还有一些其他约定，例如您将“_”放在私有变量前面。对我来说，我不喜欢这种方式，而且更喜欢这种方式，但只是想知道方法中的内容。

那么

public void MyMethod()
{
}

public string MyProperty {get; set;

}

对于 private

private void myMethod()
{
}

但是在方法中呢？

另外

public void MyMethod()
{
   string MyVariable = null;
   // or
   string myVairable = null;
}

，如果您有类似的全局变量，

public class Test
{
   private string bob;

   public Test()
   {
      bob = null;
   }
}

那么它应该是小写的（因为它是私有的）怎么样？另外，顺便说一句，最好将其设为财产，而不是公共财产，只需将其私有即可。

原文

In a book I been reading they use a capital letter for public methods and properties. I know there are some other conventions like you put "_" in front of private variables. For me I don't like that way and like this way better but just wondering about stuff in the method.

public void MyMethod()
{
}

public string MyProperty {get; set;

}

and for private

private void myMethod()
{
}

But how about in the method?

public void MyMethod()
{
   string MyVariable = null;
   // or
   string myVairable = null;
}

Also how about if you have sort of a global variable like

public class Test
{
   private string bob;

   public Test()
   {
      bob = null;
   }
}

so should it be lowercase(since it is private)? Also on a side note would it better just make it a property but instead of a public property just have it private.

分享到QQ

分享到微博

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

发布评论

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

一片旧的回忆 2024-08-13 10:00:53

以下是您的代码示例，如果它们遵循官方 Microsoft 代码样式指南（由 StyleCop 和 FxCop 强制执行），则

public void MyMethod()
{
}

public string MyProperty { get; set; }

private void MyMethod()
{
}

public void MyMethod()
{
   string myVariable = null;
}

public class Test
{
   private string bob;

   public Test()
   {
      this.bob = null;
   }
}

规范中的一些要点：所有字段都应为 private 且小写（除非它们“ re 常数）。无论访问方式如何，所有方法都应大写。如果您想公开一个字段（即使其成为public 或protected），请使用属性（如果它是protected 或public，则应大写）。如果您有属性的自动get和set（即只是get;和set;），它们可以在一行上，否则在单独的行上（如果有更多代码）。命名字段时始终以小写 az 开头，而不是下划线。大括号应位于新线上。始终使用 this. 引用非静态成员（即属性、方法、字段），以将它们与变量区分开并避免歧义。

有一个很大的列表，但这些是与您的示例最相关的。查看 code.msdn.microsoft.com/sourceanalysis

以及您在问题实际上是一个“领域”。这些永远不应该暴露（正如我上面所说），因为您暴露了您的实现，而实际上您的行为就是您应该在类型的接口上暴露的全部内容。属性允许您指定一个接口，即使它们现在作为自动属性实现，您也可以稍后更改 getter 和 setters，而无需更改接口。

Here are your code examples as they would be if they followed official Microsoft code style guidelines (enforced by StyleCop and FxCop)

public void MyMethod()
{
}

public string MyProperty { get; set; }

private void MyMethod()
{
}

public void MyMethod()
{
   string myVariable = null;
}

public class Test
{
   private string bob;

   public Test()
   {
      this.bob = null;
   }
}

Some highlights from the spec: all fields should be private and lower case (except if they're constant). All methods should be Capitalised, whatever the access. If you want to expose a field (i.e. make it public or protected), use a property (which should be capitalized if it's protected or public). If you have automatic getters and setters for properties (i.e. just get; and set;), they can be on one line, otherwise on separate lines (if there's more code). Always name fields starting with lower case a-z, not underscores. Braces should be on a new line. Always reference non-static members (i.e. properties, methods, fields) with this. to distinguish them from variables and to avoid ambiguity.

There's a huge list but these are the most relevant to your examples. Look at code.msdn.microsoft.com/sourceanalysis

And what you call 'global' in your question is in fact a 'field'. These should never be exposed (as I said above) because you're exposing your implementation when in fact your behaviour is all you should expose on the interface to a type. Properties allow you to specify an interface and, even if they're implemented as automatic properties now, you can change the getters and setters later without changing the interface.

回复收藏 0 原文

叹倦 2024-08-13 10:00:53

我推荐 Microsoft 命名指南：

http://msdn.microsoft.com/en -us/library/ms229002.aspx

有趣的是，他们没有提出如何命名隐藏在公共属性后面的私有属性的主题。我倾向于用下划线作为前缀。

一般来说，驼峰命名法，如果是参数则首字母小写。

回复收藏 0 原文

心舞飞扬 2024-08-13 10:00:53

我认为代码约定应遵循以下规则：

促进可读代码。
如果你在一个团队中工作，就做团队同意的事情。
如果你独自工作，做任何让你内心感到温暖和模糊的事情。

否则……除非有更高权力强加给你规则，否则这并不重要。

就我个人而言，我更喜欢驼峰命名法的变体以及在私有变量前加上 m_ 前缀。

另外，在我不希望其他人看到代码的个人项目中，我喜欢在我的变量名称中使用不合逻辑的幽默，即

StringBuilder duck = new StringBuilder(4096);
duck.Append(palmtree.ToString());

这让我后来笑了。

I am of the opinion that code conventions should follow the following rules:

Promote readable code.
If you're working on a team, do whatever the team agrees to.
If you're working alone, do whatever makes you feel warm and fuzzy inside.

Otherwise... it doesn't really matter unless rules are imposed upon you by a higher power.

Personally, I prefer the variation of camelCase and prefixing private variables with m_.

Also, on personal projects that I don't expect other people to ever see the code, I enjoy using non-sequitur humor in my variable names, i.e.

StringBuilder duck = new StringBuilder(4096);
duck.Append(palmtree.ToString());

This makes me laugh later.

回复收藏 0 原文

风吹雪碎 2024-08-13 10:00:53

除了窃笑所说的之外，我还要补充一点，保持一致。

您可能还想查看 MSDN 上的一般命名约定。

回复收藏 0 原文

慈悲佛祖 2024-08-13 10:00:53

C# 命名约定的另一个可靠资源是
IDesign 编码标准。它与 StyleCop / Microsoft 编码标准基本一致，但有一些细微差别。两者都同意局部变量和方法参数应该是驼峰式的，就像

    void MyMethod(int someNumber)  
    {int anotherNumber = 1;}

一般情况下，我在这一点上没有看到很多变化，大多数人似乎都遵循这个约定。
就私有成员变量/字段而言，存在更多差异。 StyleCop 提倡驼峰式格式，Juval 则采用 m_MyPrivateVariable 格式。我还看到人们使用 _MyPrivateVariable。

Another solid resource for C# naming conventions is the
IDesign coding standard. It's largely in agreement with the StyleCop / Microsoft coding standard, with small differences. Both agree that local variables and method arguments should be camel-cased, as in

    void MyMethod(int someNumber)  
    {int anotherNumber = 1;}

In general, I haven't seen many variations on that point, most people seem to follow that convention.
As far as private member variables / fields go, there is more variance. StyleCop advocates camel-casing, Juval the m_MyPrivateVariable format. I have also seen people use _MyPrivateVariable.

回复收藏 0 原文