变量名的声明
以大写形式声明变量名称的最佳方法是什么？ ..小写？ 在任何情况下都必须声明哪个区域...以及什么名称是合适的，具体取决于标准变量的滚动...有一些变量需要声明？...抱歉这个问题...我是新手编程世界......我希望不要打扰......=）
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
以大写形式声明变量名称的最佳方法是什么？ ..小写？ 在任何情况下都必须声明哪个区域...以及什么名称是合适的，具体取决于标准变量的滚动...有一些变量需要声明？...抱歉这个问题...我是新手编程世界......我希望不要打扰......=）
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（8）
在 C# 中，我们对属性和方法名使用 PascalCase，对其他成员使用 CamelCase。 对于常量，我们使用 CAPS_WITH_UNDERSCORE。 对于 html 元素，使用匈牙利表示法。 （我认为这些是微软标准。）
In C#, we use PascalCase for properties and methodnames and camelCase for other members. For constants we use CAPS_WITH_UNDERSCORE. For the html elements hungarian notation is used. (I think these are Microsoft standards.)
“当在罗马时......”的必然结果是像以前的编码员所做的那样。 当您正在处理其他开发人员的代码或项目时，您应该将您的风格与现有风格相匹配。 虽然一开始看到一个奇怪的约定会让人感到困惑和难以处理，但这与整理一个每两个函数都会切换符号和样式的文件相比并不算什么。
当您从事自己的项目时，或者作为单个开发人员，您可以在合理范围内做最舒服的事情。
A corollary to "When in Rome..." is to do as the previous coder has done. When you are working on another developers code or project, you should match your style to the existing style. While seeing a weird convention is puzzling and hard to deal with at first, it is nothing compared to sorting out a file that switches notation and style every couple of functions.
When working on your own project, or as a single developer you can do what is most comfortable within reason.
这里有一些有关各种语言的编码标准的链接..
它有变量命名的标准等等。
C# 编码标准
C++ 编码标准
Java 编码标准
这里是 通用编码标准文章，解释编码标准背后的推理。
Well here are some links for the coding standards for various languages..
This has standards for variable naming and a lot more.
C# coding standards
C++ coding standards
Java coding standards
And here is generic coding standards article that explains the reasoning behind the coding standards.
至少对于 C 和 C++，我们可以使用 匈牙利表示法
Atleast for C and C++ we can use Hungarian notation
如果：
然后只是使其尽可能具有可读性。 未来，成群结队的开发人员将会赞扬你没有给他们带来可怕的代码。
我个人最喜欢的是常量
(IQ_LIMIT)全部大写和下划线，其他所有内容(getItembyId(), itemCount)都使用驼峰式大小写。 但这是个人喜好，而不是写在石碑上的东西。If:
then just make it as readable as possible. Hordes of developers in the future will sing praises to your name for not inflicting horrible code on them.
My personal favorite is all uppercase and underscores for constants
(IQ_LIMIT)and camel case for everything else(getItembyId(), itemCount). But that's personal preference, not something written on stone tablets.这实际上取决于您使用的编程语言以及一组遵循的任何编码约定。
例如，有用于编写 C 代码的 GNU 编码标准，其中涵盖 变量名称一直到 行缩进。
对于语言，Java 编程语言的代码约定 列出了 变量的大小写和命名、包、类、方法、 Java 编程语言中的等等。
It really depends on the programming language you use, and any coding conventions that are followed by a group.
For example, there is the GNU coding standards for writing C code which covers variable names down to the indentation of lines.
For languages, the Code Conventions for the Java Programming Language lays out some coding conventions for capitalization and naming of variables, packages, classes, methods, etc in the Java programming language.
在罗马，入乡随俗。 每种语言通常对于此类事物都有自己的习语。
When in Rome, do as the Romans. Each language usually has its own idioms with respect to these sorts of things.
IMO，了解变量的范围是最重要的。 您应该一目了然地知道有多少代码可以影响变量以及您的更改将影响多少代码。 通过这种方式，可以保持封装（以及您的理智）。 您不会意外地更改全局变量并神秘地控制整个程序。 而且它们应该像拇指酸痛一样脱颖而出，乞求被重构。
因此，全局变量的第一个字母大写（其中“全局”是可以被多个函数看到的任何变量），其他所有变量的第一个字母小写。 传统上，常量全部大写。
因此，在 StudlyCaps 风格中，它将是：
并使用下划线：
您是否使用 StudlyCaps 或下划线取决于您的编程语言和本地风格（我更喜欢下划线，因为它们的可读性并且不会混淆大小写）。
IMO, knowing the scope of a variable is the most important thing. You should know at a glance how much code can effect a variable and how much code will be effected by your changing it. In this way encapsulation (and your sanity) can be maintained. You won't accidentally change a global variable and mysteriously hose the whole program. Also they should stand out like a sore thumb just begging to be refactored away.
Therefore upper-case the first letter for globals (where "global" is any variable that can be seen by more than one function) and lower-case the first letter for every else. Constants traditionally get all caps.
So in studlyCaps style it would be:
And using under scores:
Whether you use studlyCaps or under scores depends on your programming language and local style (I prefer under scores for their readability and no confusion about capitalization).