Именование: Почему именованные константы должны быть в верхнем регистре в C ++ / Java?

Question

Я знаю, что для C ++ и Java это хорошо установленное соглашение об именах, что константы должны быть записаны в верхнем регистре, с подчеркиванием для разделения слов. Вот так (пример Java):

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

Это соглашение об именах легко понять и соблюдать, но я спрашиваю себя, зачем выбирать это соглашение об именах по сравнению с обычным соглашением об именах для переменных:

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

Кажется, нет необходимости менять вид констант. Если мы хотим присвоить им значение, компилятор все равно предотвратит это. На самом деле это создает проблемы, если позже константа будет изменена на правильную переменную (потому что цвета, например, настраиваются).

Так какова основная причина писать именованные константы в верхнем регистре? Исторические причины?

Answer 1

Я думаю, что это не техническая проблема, а скорее психологическая. Соглашения об именах предназначены не для обработки компилятором (на самом деле компьютер не обращает внимания на имена), а для программиста, который просматривает код, чтобы получить как можно больше информации с минимальными усилиями.

Использование другого соглашения об именах ясно говорит читателю, что то, что вы читаете, является ИСПРАВЛЕННЫМ во время компиляции, и вам не нужно следовать коду, чтобы определить, где и как получилось значение.

Answer 2

Если я знаю, что что-то является константой, я могу ссылаться на нее несколько раз и знаю, что это не изменится. Другими словами, я знаю, что:

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

совпадает с:

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

Это может быть полезно знать иногда. Лично я предпочитаю соглашение об именах .NET, которое заключается в использовании регистра Pascal для констант (и методов):

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

Я не большой поклонник кричащих дел ... но мне нравится, что константы - это, очевидно, константы.

Answer 3

Я могу себе представить, что изначально, в дни Си, люди могли бы реализовывать «константы» символически, используя препроцессор:

typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff

Такие "константы" - это просто предварительно подтвержденные литералы, и поэтому они не ведут себя как переменные. Например, нельзя взять адрес такой «константы»:

Color *p = &BACKGROUND_COLOR; // Breaks!

По этой причине имеет смысл выделять их, поскольку они на самом деле не просто "переменные, которые вы не можете изменить".

Answer 4

Я верю, что в C ++ это соглашение перенесено со времен использования препроцессора на #define константные значения. В то время это было сделано для того, чтобы препроцессор не попрал весь ваш исходный код, поскольку обычные соглашения для имен функций и переменных C делали их смешанными или строчными.

С точки зрения C ++ я бы сказал, что делать константы в верхнем регистре плохой идеей. Из-за этого мне пришлось отлаживать более одной проблемы сборки - помните, что препроцессор C ++ ничего не знает о пространствах имен и области именования и с радостью заменит то, что считает подходящим, даже если это довольно неуместно.

Answer 5

В C (а затем в C ++) символы, которые были определены с помощью директивы препроцессора #define, были написаны заглавными буквами как громкий сигнал разработчикам о том, что код не такой, как кажется, и не должен рассматриваться как нормальный символ. Константы изначально не существовали в K & R C (хотя const был возвращен из C ++ позже), поэтому разработчики использовали вместо него #define, отсюда и ограничения.

По какой-то причине это стало извращенным в Java как "константы - это заглавные буквы", отсюда и текущее ошибочное соглашение (IMO).

Answer 6

Я думаю, что заглавные константы - плохое наследие от C. Логика та же, что и при использовании подчеркивания в качестве префиксов для частных членов. Это технический материал, который уже выражается ключевыми словами Java, такими как private или, в случае констант, static final.

Смотри также: http://weblogs.java.net/blog/2006/09/28/case-against-uppercases

Answer 7

Не используйте ALL_CAPS для констант только потому, что константы раньше были макросами.

Эта цитата из C ++ Core Guidelines подводит итоги.

Answer 8

С помощью заглавных констант длинные формулы намного легче читать, вам не нужно угадывать, какой элемент может меняться, а какой нет. Это, конечно, всего лишь конвенция, но полезная.

Answer 9

В основном, когда люди были влюблены в C, а C ++ и Java были либо новыми, либо еще не созданы, люди использовали все заглавные буквы для имен констант препроцессора, чтобы указать, что они на самом деле не были переменными.

#define INT_CONST 4
#define STRING_CONST "Yello."
#define FLOAT_CONST 3.6122448

Учитывая, что это был единственный реальный способ определения истинной константы в C (все еще возможно изменить const переменные, если вы знаете, как), подобные константы препроцессора просто рассматривались как константы, и как таковое значение имена всех заглавных букв переместились из констант препроцессора в обычные константы. Затем это перенесено на более поздние языки, став стандартной практикой "consts = capitals".

Однако другие языки имеют свой собственный предпочтительный стиль (например, C # и .NET предпочитают PascalCase), поэтому, как правило, лучше использовать предпочтительный стиль, если он есть.

Answer 10

Это обходной путь для ваших инструментов разработки, которые не могут определить свойства идентификатора удобным способом.

Очень похоже на венгерскую нотацию.

Когда ваша IDE станет лучше, вам не понадобится соглашение об именах, кроме того, которое предписывает, что имя является исчерпывающей информацией о том, что означает идентификатор.

Даже это может развиваться: почему бы не создать систему программирования, в которой вы просто создаете идентификаторы и добавляете в нее свойства, такие как «краткое описание», «тип», ... Когда прибывает инструмент, который может сделать это удобным способом Я в. " Преднамеренное программирование " - подсказка.