Именование: почему переменные named должны быть прописными в 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

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

Joel Spolsky упомянул в one of his essays, насколько впечатлен он был со временем компиляции новой версии Turbo Pascal.

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

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

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

Answer 2

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

typedef unsigned int Color; 
#define BACKGROUND_COLOR 0xffffff 

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

Color *p = &BACKGROUND_COLOR; // Breaks! 

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

так же, как:

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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

Answer 11

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

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

Answer 12

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

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

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

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

Answer 13

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

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

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

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

Answer 14

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

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

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

const float kFixedRadius = 3.141; 

Answer 15

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

Это quote из Руководства по основным принципам C++ суммирует все это.

Answer 16

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

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