Подтвердить что ты не робот

Именование. Почему имена должны быть заглавными в С++/Java?

Я знаю, что для С++ и 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;

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

Итак, какова конечная причина для написания названных констант в верхнем регистре? Исторические причины?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

совпадает с:

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

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

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

Я не большой поклонник кричащего случая... но мне нравятся константы, являющиеся явно константами.

Ответ 3

Я могу себе представить, что изначально, еще в C дни, люди будут реализовывать "константы" символически, используя предварительный процессор:

typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff

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

Color *p = &BACKGROUND_COLOR; // Breaks!

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

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

Этот quote из С++ Core Guidelines суммирует все это.

Ответ 10

Возможно, вы правы. Компьютеры и компиляторы (особенно) были не такими быстрыми, как сегодня.

Джоэл Спольский упомянул в одном из своих эссе, как он впечатлился с временем компиляции новой версии Turbo Pascal.

Помню, когда компиляция не слишком большой программы (10-20KLOC) с наложениями в Turbo Pascal 5.0 на ПК XT 10 МГц заняла около 20 минут...

Я предполагаю, что ожидание компиляции для обнаружения ошибки было неприемлемым.

И подобное соглашение помогает избежать ошибок и тратить время во время сломанной компиляции.

Ответ 11

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

Во многом как венгерская нотация.

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

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

Ответ 12

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

Ответ 13

На самом деле большинство рекомендаций по именованию С++ (включая ISO, Boost, Sutter и Stroustrup и Google) категорически препятствуют постоянным именам со всеми ограничениями. Это связано с тем, что макросы также используют все кепки, и они могут быть завалены во всех файлах заголовков, что потенциально создает странное поведение. Тем не менее, люди все еще используют все кепки, потому что они учатся из старого C/K & R или старого унаследованного кода. Однако в Modern С++ новом коде вы должны избегать использования всех кепок для чего-либо, кроме макросов.

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

Большинство рекомендаций С++ теперь согласны с использованием "k" в качестве префикса для константы, за которым следует имя либо с подчеркиванием, либо с CamelCase. Я лично предпочитаю kCameCase, потому что он легко позволяет отличить от переменных, которые называются с under_scores.

const float kFixedRadius = 3.141;

Ответ 14

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

На самом деле нет причин, касающихся компиляции. Соглашения об именах - это просто соглашения, а не технические ограничения.

Ответ 15

Кодирование конверсий должно улучшить читаемость. Вам не нужно использовать буквы. Например, Java допускает символ $.

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

Вы также можете указать свои переменные, но это не значит, что это хорошая идея.;)

Ответ 16

Это определенно техническая проблема на Java. Рассмотрим:

import static com.test.constants.white;
public class Foo {
  void bar(){
    //String white = "black";
    String whatAmI = white;
  }
}

Какова ценность "whatAmI" до и после раскола предыдущей строки?

Если имя константы имеет то же соглашение, что и имя локальной переменной, это вызовет проблемы с REAL. Константы всегда должны иметь соглашение UPPERCASE, чтобы избежать этого.