Существуют ли какие-либо технические причины для использования подчеркивания в таких именах, как (например) scoped_lock в библиотеке Boost? Почему бы не назвать его "ScopedLock"?
Обратите внимание, что я не спрашиваю о стилистических причинах.
Технические причины для имен, содержащих символы подчеркивания?
Ответ 1
Из Повысить требования к библиотеке и рекомендации,
Учитывая намерение предложить части повышения для следующего пересмотра стандартной библиотеки С++, повышение решило следовать стандартным соглашениям с библиотекой.
Ответ 2
Нет технической причины. Если вы проигнорируете стилистическую причину, вы можете написать scopedlock, istreamiterator и подобное.
Ответ 3
Считываемость, если вы можете назвать это техническое пространство, обычно запрещается, а подчеркивание - ближайший матч. Случай с верблюдом ужасен для чтения (часто он зарезервирован для классов как конвенция).
Ответ 4
Подчеркивает улучшение интерфейса с человеческим нейронным оборудованием, создавая больше пространства между отдельными словами.
Раньше я предпочитал верблюд, когда был маленьким, и имел небольшой монитор и маленькие руки. Я, в основном, прихожу.
Ответ 5
Субъективно я нахожу подчеркивание немного переборки в коде. Достаточно злоупотреблять не-буквенно-цифровыми символами в коде, как есть, я думаю, что введение их в идентификаторы немного выше. Сверху моей головы рассмотрим этот отрывок из ошибки шаблона boost:
Derived=boost::transform_iterator<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>>,
Base=boost::counting_iterator<size_t>,
Value=boost::detail::transform_iterator_base<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>,boost::use_default,boost::use_default>::cv_value_type,
Traversal=boost::use_default,
Reference=boost::detail::transform_iterator_base<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>,boost::use_default,boost::use_default>::reference,
Difference=boost::use_default
по сравнению со следующим, который был преобразован в случай Паскаля (я предпочитаю этот метод):
Derived=boost::TransformIterator<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>>,
Base=boost::CountingIterator<SizeT>,
Value=boost::detail::TransformIteratorBase<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>,boost::UseDefault,boost::UseDefault>::CVValueType,
Traversal=boost::UseDefault,
Reference=boost::detail::TransformIteratorBase<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>,boost::UseDefault,boost::UseDefault>::Reference,
Difference=boost::UseDefault
Я вижу преимущество подчеркивания, когда оно берется изолированно, но со всеми нашими другими символами я думаю, что мы должны сосредоточиться на создании программ, которые читаются ближе к английскому, а не к подчеркиванию.
Ответ 6
Нет технической причины.
Переменные имена в С++ должны только
- Начните с буквы или подчеркивания
- Содержит только число, буквы (заглавные или нет) и символы подчеркивания
Использование this_way или ThisWay - это только вопрос стиля.
Ответ 7
Там нет технической причины, но есть причина. Вы должны согласиться со мной, что гораздо легче читать scoped_lock, затем scopedlock, но scopedlock тоже сделает это. Тем не менее, с подчеркиванием легче читать, ИМХО.
Но хорошо написанный код - это разборчивый код. Это часть знания, чтобы хорошо программировать.
Ответ 8
Единственная техническая причина заключается в удобочитаемости, поскольку использование CamelCase может привести к неправильной интерпретации, особенно когда речь идет об аббревиатурах во всех кепках. Гнездо GPS выйдет как GPSSocket. Есть несколько лучших примеров, но мой ментальный блок не позволяет мне записывать их.: - (
Если вы хотите получить техническую информацию, нет причин, потому что подчеркивание является жизнеспособным символом для идентификаторов.
Ответ 9
Хотя технически говоря, нет никакой разницы, могут возникнуть проблемы, вызванные окружающей средой. Например, если вы включите windows.h, вы не захотите называть любую функцию TextOut, даже если это то, что делает функция. Причина в том, что это имя будет заменено препроцессором из-за того, что TextOut является макросом в API win32. По этой причине руководитель проекта, возможно, пожелает наложить случай не верблюда в качестве стандарта.
Таким образом, могут быть технические причины, но нет причины, навязываемой самим языком. Это не похоже на Java (он все еще делает это?), Когда вы вынуждены компилятором использовать случай с верблюдом.
Ответ 10
Нет технической причины. Это чисто стилистика. Чтобы быть конкретным, С++ отображает все символы, начинающиеся с буквы, подчеркивания или знака доллара. Единственная разница в том, как они объявлены. Если вы хотите, вы можете назвать свой класс "вещью" как Thing, Thing, Thing, Thing или даже T_h_I_n_G_$, если хотите... это не повлияет на компилятор, Тем не менее, это действительно имеет значение для других людей, которые будут смотреть и использовать ваш код. И если вы заберете это слишком далеко (например, последние пару примеров, которые я перечислял), вы можете даже найти свою жизнь в опасности в какой-то момент (сердитый программист может быть ужасающим).
Ответ 11
Нет технической причины как таковой. Но у меня есть причина, отличная от моего блеска, "потому что они выглядят так же".
Моя причина в том, что я считаю полезным отличать переменные-члены от переменных, отличных от членов, удобным образом. В частности, когда я переношу данные из локальной переменной в переменную-член, например, внутри конструктора. Пример дешевле:
class Socket
{
public:
Socket(const sockaddr_in& group)
: group_(group)
{
}
private:
sockaddr_in group_;
};
Если вы спросите мое мнение, большинство переменных схем именования ужасны, потому что существует слишком много правил и слишком много способов, которыми они ломаются. Классический пример ужасной схемы именования венгерский, но даже от того, что я сделал что-то полезное: префикс m_ для переменных-членов иногда пригождался. Не слишком часто, но достаточно часто для того, чтобы заимствовать идею, если не метод.
Ответ 12
Нет технических причин или против, кроме того, что навязывается языком, который в этом случае не существует.
Ответ 13
Эта причина ограничивает края стилистической, но поскольку никто еще не упомянул об этом до сих пор, я просто добавлю, что в чувствительном к регистру языке, таком как С++, подчеркивания более запоминаются, чем капитализация.
Например, иногда вы можете видеть scopedLock вместо scopedLock. Если вы никогда не используете кепки, это всего лишь одна вещь, которую нужно отслеживать.
Ответ 14
Ну, а не компиляторы, но prefast rulesets иногда пытаются обеспечить соблюдение соглашений об именах. Чтобы быть откровенным, так много конвенций действительно запутывают; особенно когда нужно поддерживать старый код, а также писать новый код на нескольких языках.
Ответ 15
Одна техническая причина, о которой я могу думать (особенно для имен функций членов), - это позволить утиную печать. Например, следующие классы повышения могут использоваться (в некоторой степени), когда вы ожидаете контейнер STL:
- boost:: ptr_container и семья
- boost:: контейнеры multi_index
- подталкивание:: массив
- boost:: dynamic_bitset (вместо boost:: bitset)
Ответ 16
Когда C был изобретен, он использовался в Unix, а Unix управлялся с терминалов, которые напоминали пишущие машинки. Некоторые терминалы имели как верхние, так и строчные буквы, но некоторые терминалы имели только верхний регистр. Если вы хотите использовать систему Unix, но все приятные терминалы уже были заняты вашими жадными эгоистичными коллегами, вы застряли со старым терминалом. Вот почему, если вы вводите имя пользователя во всех строчных символах, Unix предполагает, что у вас нет нижнего регистра. Каждая строчная буква отображается как соответствующая буква верхнего регистра, и каждая буква верхнего регистра отображается как звездочка, за которой следует сама.
Теперь представьте себе верблюд, а не подчеркивания.
Кстати, C был основан более или менее свободно на PL/I. PL/I был пробит в карты, которые первоначально не поддерживали нижний регистр, и в итоге их можно было взломать, чтобы поддерживать строчные буквы, но не в удобном для перфорации. Кроме того, он обычно печатался принтерами, которые не поддерживали нижний регистр, хотя некоторые сделали. Так что нижний регистр вышел, случай с верблюдом вышел, а программисты были использованы для подчеркивания. (За исключением программистов Cobol, которые использовались для обозначения минусов в середине идентификаторов, означающих, что это-есть-идентификатор, этот минус минус минус-идентификатор.)
Паскаль был изобретен позже, в среде, где буквы нижнего регистра были более распространенными, но все же не универсальными. Случай с верблюдом стал возможным, потому что Паскаль был нечувствителен к регистру. Случай с верблюдом стал популярным, потому что Паскаль не допускал подчеркивания в идентификаторах.
Итак, если вам нравится случай с верблюдом в сочетании с чувствительностью к регистру, вы получаете половину.
Ответ 17
IMHO, довольно разумно принять стиль стандартной библиотеки для используемого вами языка. Если это Java, это scopedLock, если это С++, это scoped_lock. Если это Lisp, он заблокирован.
Не то, чтобы это действительно имело значение, во всяком случае.