C# 中是否有命名参数的样式指南?

发布于 2025-01-06 05:55:20 字数 382 浏览 0 评论 0原文

MSDN - 冒号后的空格。 这与 Objective-C 不同,在 Objective-C 中我没有看到人们在冒号后面使用空格。我认为这可能是语法突出显示尚未跟上该功能的问题,但我没有良好的 IDE 经验。我在 Mac 上使用 MonoDevelop 与 Unity 结合使用,它既不提供语法着色,也不提供命名参数的自动完成功能。 有很多内容;如果您知道我要求在内部或其他地方存在什么,请告诉我。我还没找到。

MSDN - spaces after the colon.
That's different than Objective-C, where I don't see people using a space after the colon. I'm thinking it might be an issue where syntax highlighting hasn't caught up to the feature yet, but I have no experience in a good IDE. MonoDevelop, which I use on the Mac with Unity, neither provides syntax coloring nor autocomplete for named parameters. There is a lot there; if you know what I'm asking to exist within, or elsewhere, please let me know. I haven't found it yet.

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

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

发布评论

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

评论(3

南街女流氓 2025-01-13 05:55:20

Microsoft 在 MSDN 上发布了一些常识性指南,在我看来,一致性与惯例一样重要。如果您还没有这样做,那么值得查看 Stylecop 了解代码样式和标准。

名称指南

来自:参数名称

选择好的参数名称可以显着提高可用性
你的图书馆。一个好的参数名称应该表明什么数据或
功能受参数影响。

请在参数名称中使用驼峰式大小写。一定要使用描述性参数
名称。

在大多数情况下,参数的名称及其类型应该是
足以确定参数的用法。

考虑使用基于参数含义的名称而不是名称
基于参数的类型。

在开发者工具和文档中,参数的类型通常是
可见的。通过选择一个描述用途或含义的名称
参数,您为开发人员提供了有价值的信息,可以帮助
他们确定适合其任务的成员和正确的数据
传递给成员。

Microsoft has some common sense guidelines published on MSDN, in my opinion its the uniformity that counts as much as the convention. If you are not already doing so its worth looking at Stylecop for code styling and standards.

Guidelines for Names

From: Names of Parameters

Choosing good parameter names can significantly improve the usability
of your library. A good parameter name should indicate what data or
functionality is affected by the parameter.

Do use camel casing in parameter names. Do use descriptive parameter
names.

In most scenarios, the name of the parameter and its type should be
sufficient to determine the parameter's usage.

Consider using names based on a parameter's meaning rather than names
based on the parameter's type.

In developer tools and documentation, the parameter's type is usually
visible. By selecting a name that describes the usage or meaning of
the parameter, you give developers valuable information that helps
them identify the right member for their task and the right data to
pass into the member.

内心激荡 2025-01-13 05:55:20

如果这是您所要求的,没有人强迫您使用某种特定的风格。您可以根据需要在不带空格的情况下编写它,或者在冒号后面添加空格,或者在冒号之前添加空格,或者在冒号周围添加空格。

但是,恕我直言,当您在冒号后仅使用一个空格时,它的可读性更强。

Nobody forces you to use some specific style, if this is what you're asking about. You can write it without the spaces, or with the space after the colon, or with the space before the colon, or with the spaces surrounding the colon, as you wish.

However, IMHO, it is more readable when you only use a single space after the colon.

薄荷港 2025-01-13 05:55:20

风格指南应该由开发团队产生。每种语言都有自己应该遵循的习惯用法,但细节需要由团队定义。
这同样适用于命名约定。

把它们写下来,传阅并获得每个人的同意。如果你正在做开源,我相信社区会给你反馈。

Style guides should emerge from the development team. Each language has its own idioms that should be followed but the details need to be defined by the team.
The same applies to naming conventions.

Write them down, circulate and get everybody's agreement. If you're doing open source I'm sure the community will give you feedback.

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