命名:为什么在 C++/Java 中命名常量应该全部大写?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/838929/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-11 20:03:56  来源:igfitidea点击:

Naming: Why should named constants be all uppercase in C++/Java?

javac++naming-conventions

提问by Mnementh

I know, that for C++ and Java it is a well established naming convention, that constants should be written all uppercase, with underscores to separate words. Like this (Java-example):

我知道,对于 C++ 和 Java,这是一个完善的命名约定,常量应该全部大写,并用下划线分隔单词。像这样(Java示例):

public final static Color BACKGROUND_COLOR = Color.WHITE;
public final static Color TEXT_COLOR = Color.BLACK;

This naming convention is easy to understand and to follow, but I ask myself, why choose this naming convention over the normal naming-convention for variables:

这个命名约定很容易理解和遵循,但我问自己,为什么选择这个命名约定而不是变量的正常命名约定:

public final static Color backgroundColor = COLOR.WHITE;
public final static Color textColor = COLOR.BLACK;

Theres seems to be no need to change the look of constants. If we want to assign a value to them, the compiler will prevent this anyways. Actually it makes problems, if later the constant will be changed into a proper variable (because the colors get configurable for instance).

似乎没有必要改变常量的外观。如果我们想给它们赋值,编译器无论如何都会阻止。实际上它会产生问题,如果稍后将常量更改为适当的变量(因为例如颜色可以配置)。

So what's the ultimate reason to write named constants all uppercase? Historical reasons?

那么将命名常量全部大写的最终原因是什么?历史原因?

回答by Grzegorz Gierlik

Probably you are right. Computers and compilers (especially) were not so fast as today.

可能你是对的。计算机和编译器(尤其是)没有今天那么快。

Joel Spolsky mentioned in one of his essayshow impressed he was with compilation time of new version of Turbo Pascal.

Joel Spolsky 在他的一篇文章中提到他对新版本 Turbo Pascal 的编译时间印象深刻。

I remember when compilation of not too big program (10-20KLOC) with overlays in Turbo Pascal 5.0 on PC XT 10MHz took about 20 minutes...

我记得在 PC XT 10MHz 上用 Turbo Pascal 5.0 编译不太大的程序 (10-20KLOC) 和覆盖层需要大约 20 分钟......

I suppose that waiting for compilation to detect error was not acceptable.

我想等待编译检测错误是不可接受的。

And convention like that helps to avoid errors and wasted time during broken compilation.

像这样的约定有助于避免错误编译过程中的错误和浪费时间。

回答by unwind

I can imagine that initially, back in the C days, people would implement "constants" symbolically, using the pre-processor:

我可以想象,最初,回到 C 时代,人们会使用预处理器象征性地实现“常量”:

typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff

Such "constants" are just prettified literals, and as such they don't behave quite as variables. You can't, for example, take the adress of such a "constant":

这样的“常量”只是美化的文字,因此它们的行为不像变量。例如,您不能使用这样一个“常量”的地址:

Color *p = &BACKGROUND_COLOR; // Breaks!

For this reason, it makes sense to have them "stand out", as they're really not just "variables you can't change".

出于这个原因,让它们“脱颖而出”是有道理的,因为它们真的不仅仅是“你无法改变的变量”。

回答by tomash

With uppercase constants long formulas are much easier to read, you don't have to guess which element can vary and which can not. It's of course only a convention, but helpful one.

使用大写常量,长公式更容易阅读,您不必猜测哪些元素可以变化,哪些不能。这当然只是一个约定,但很有帮助。

回答by David Rodríguez - dribeas

I think it is not a technical problem but rather a psychological one. Naming conventions are not for the compiler to process (the computer does not really mind names) but rather for the programmer that is browsing the code to have as much information as possible with as little effort as required.

我认为这不是技术问题,而是心理问题。命名约定不是供编译器处理(计算机并不真正介意名称),而是供浏览代码的程序员以尽可能少的工作量获得尽可能多的信息。

Using a different naming convention is clearly telling the reader that what you are reading is something that is FIXED at compile time and you don't need to follow through code to determine where and how the value got there.

使用不同的命名约定清楚地告诉读者你正在阅读的是在编译时固定的东西,你不需要通过代码来确定值在哪里以及如何到达那里。

回答by Jon Skeet

If I know something is a constant, I can refer to it multiple times and know it won't change. In other words, I know that:

如果我知道某件事是一个常数,我可以多次引用它并且知道它不会改变。换句话说,我知道:

Color black = Colors.BLACK;
foo(black);
foo(black);

is the same as:

是相同的:

foo(Colors.BLACK);
foo(Colors.BLACK);

That can be useful to know sometimes. Personally I prefer the .NET naming convention, which is to use Pascal case for constants (and methods):

有时知道这一点很有用。我个人更喜欢 .NET 命名约定,即对常量(和方法)使用 Pascal 大小写:

Foo(Colors.Black);
Foo(Colors.Black);

I'm not a big fan of shouty case... but I do like constants being obviously constants.

我不是大喊大叫的忠实粉丝...但我确实喜欢常量显然是常量。

回答by xtofl

It's a workaround for your development tools not being able to spot the properties of an identifier in a convenient way.

这是您的开发工具无法以方便的方式发现标识符的属性的一种解决方法。

Much like Hungarian notation.

很像匈牙利符号。

When your IDE gets better, you won't need any naming convention but the one that dictates that a name is comprehensive information on what an identifier means.

当您的 IDE 变得更好时,您将不需要任何命名约定,但要求名称是关于标识符含义的全面信息的约定。

Even that may evolve: why not create a programming system where you just create identifiers, and add properties to it like "brief description", "type", ... When the tool arrives that can do this in a convenient way, I'm in. "Intentional Programming" is a hint.

甚至这可能会发展:为什么不创建一个编程系统,您只需创建标识符,并为其添加属性,例如“简要描述”、“类型”……当可以方便地完成此操作的工具出现时,我m in. “意向编程”是一个提示。

回答by ewh105

When programming, it is important to create code that is understandable by humans. Having naming conventions helps to do this. This is best when looking at code that you didn't write and makes the code more maintainable because it is easy to distinguish from constants and variables.

在编程时,创建人类可以理解的代码很重要。命名约定有助于做到这一点。这在查看不是您编写的代码时是最好的,并且使代码更易于维护,因为它很容易与常量和变量区分开来。

回答by Timo Geusch

I believe in C++ it's a convention carried over from the days of using the preprocessor to #define constant values. Back then, it was done to avoid having the preprocessor trample all over your source code, as the usual conventions for C function and variable names would make them mixed case or lower case.

我相信在 C++ 中,这是从使用预处理器来#define 常量值的日子延续下来的约定。当时,这样做是为了避免预处理器践踏您的源代码,因为 C 函数和变量名称的通常约定会使它们混合大小写或小写。

From a C++ point of view, I would say that it's a bad idea to make your constants all-uppercase. I've had to debug more than one build problem because of this - remember that the C++ preprocessor does know nothing about namespaces and naming scope and will happily substitute what it thinks is appropriate even though it is rather inappropriate.

从 C++ 的角度来看,我会说让你的常量全部大写是一个坏主意。由于这个原因,我不得不调试多个构建问题——请记住,C++ 预处理器对命名空间和命名范围一无所知,并且会很乐意替换它认为合适的内容,即使它相当不合适。

回答by Peter Lawrey

Coding conversions are to improve readability. You don't have to use letters. Java allows $ symbol for example.

编码转换是为了提高可读性。您不必使用字母。例如,Java 允许 $ 符号。

public final static Color $$ = COLOR.WHITE;
public final static Color $_ = COLOR.BLACK;

You could number your variables too, but that doesn't mean its a good idea. ;)

您也可以为变量编号,但这并不意味着它是一个好主意。;)

回答by deamon

I think uppercase constants are a bad heritage from C. The logic behind is the same as when using underscores as prefixes for private members. This is technical stuff which is already expressed by Java keywords like privateor, in the case of constants, static final.

我认为大写常量是 C 的糟糕遗产。背后的逻辑与使用下划线作为私有成员前缀时的逻辑相同。这是技术性的东西,已经用 Java 关键字表达了,例如,private或者,在常量的情况下,static final