Технические причины имен, содержащих символы нижнего подчеркивания?

ИМХО, вполне разумно принять стиль стандартной библиотеки для используемого вами языка. Если это Java, это scopedLock, если это C ++, это scoped_lock. Если это Лисп, это блокировка области видимости.

Во всяком случае, это не имеет значения.

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

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

Теперь представьте верблюжий корпус вместо подчеркивания.

Между прочим, C был основан более или менее свободно на PL / I. PL / I был перфорирован в карты, которые изначально не поддерживали нижний регистр, и в конечном итоге его можно было взломать для поддержки нижнего регистра, но не в удобной для перфорации манере. Кроме того, его обычно печатали принтеры, которые не поддерживали строчные буквы, хотя некоторые из них поддерживали. Таким образом, нижний регистр был исключен, верблюжий регистр был исключен, а программисты использовали символы подчеркивания. (За исключением программистов на языке Cobol, которые привыкли ставить знаки минус в середине идентификаторов, означая, что это-есть-идентификатор, а не этот минус - это минус-идентификатор.)

Паскаль был изобретен позже, в среде, где буквы нижнего регистра были более распространенными, но все же не универсальными. Верблюжий регистр стал возможным, потому что Паскаль был нечувствителен к регистру. Регистр Camel стал популярным, потому что Паскаль не допускал подчеркивания в идентификаторах.

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

Нет никаких технических причин за или против, кроме тех, которые навязываются языком, которого в данном случае не существует.

Нет технической причины. Это чисто стилистически. Чтобы быть конкретным, C ++ рассматривает все символы, начинающиеся с буквы, подчеркивания или знака доллара, одинаково. Единственная разница в том, как они объявлены. При желании вы можете назвать свой класс «вещь» как Thing , THING , thing , tHiNg или даже . T_h_I_n_G _ $ , если хотите ... это не повлияет на компилятор. Однако он действительно имеет значение для других людей, которые будут смотреть и использовать ваш код. И если вы зайдете слишком далеко (как, например, в последней паре примеров, которые я привел), в какой-то момент вы можете даже оказаться в опасности (сердитый программист может быть ужасной вещью).

Технической причины как таковой нет. Но у меня есть причина, отличная от моей бойкости, «потому что они выглядят kewl».

Моя причина в том, что я считаю полезным отличать переменные-члены от переменных, не являющихся членами, удобным способом. В частности, когда я передаю данные из локальной переменной в переменную-член, например, в конструкторе. Дешевый пример:

class Socket
{
public:
  Socket(const sockaddr_in& group)
  :  group_(group)
  {
  }
private:
  sockaddr_in group_;
};

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

Нет никаких технических причин.

Имена переменных в C ++ должны только

• начинаться с буквы или подчеркивания
• содержать только цифры, буквы (с заглавной или нет) и подчеркивания

Использование this_way или ThisWay - это просто вопрос стиля.

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

• boost :: ptr_container и семейство
• контейнеры boost :: multi_index
• boost :: array
• boost :: dynamic_bitset (вместо boost :: bitset)

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

Например, иногда вы можете увидеть scopedLock вместо ScopedLock . Если вы никогда не используете заглавные буквы, вам нужно следить только за одним делом меньше.

Единственная техническая причина заключается в удобочитаемости, потому что использование CamelCase может привести к неправильной интерпретации, особенно когда речь идет о сокращениях, написанных заглавными буквами. Гнездо GPS получится как GPSSocket. Есть несколько лучших примеров, но мой умственный блок не позволяет мне их записать. : - (

Если вы хотите получить техническую информацию, нет причин, так как подчеркивание является подходящим символом для идентификаторов.

Подчеркивания улучшают интерфейс с человеческим нейронным оборудованием, создавая больше места между отдельными словами.

Я предпочитал верблюжий футляр, когда был маленьким, и у меня был маленький монитор и маленькие руки. Хотя в основном я приходил в себя.

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

Нет технической причины, но есть причина. Согласитесь со мной, что scoped_lock , затем scopedlock , гораздо проще читать, но scopedLock тоже подойдет. Все же с подчеркиванием легче читать, ИМХО.

Но хорошо написанный код - это читаемый код. Это часть умения хорошо программировать.

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

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

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

Хотя с технической точки зрения нет никакой разницы, могут быть проблемы, вызванные окружающей средой. Например, если вы включаете windows.h, вы не захотите называть какую-либо функцию TextOut, даже если это то, что функция делает. Причина в том, что это имя будет заменено препроцессором из-за того, что TextOut является макросом в Win32 API. По этой причине руководитель проекта может пожелать ввести в качестве стандарта случай, не связанный с верблюдами.

Таким образом, могут быть технические причины, но нет причин, навязанных самим языком. Это не похоже на Java (она все еще делает это?), Где компилятор вынуждает вас использовать верблюжий регистр.

Нет технической причины. Если игнорировать стилистическую причину, можно написать scopedlock , istreamiterator и т.п.