Комментарии 36
И вместо местоимений «он» или «она» нужно использовать ангийский «they» или «their» в качестве местоимения единственного числа (видимо, на манер устаревшего местоимения «онЕ»).
Лучше бы вернули thou/thee в пару к you.
Чем лучше? Это ж второе лицо, а нужно третье...
Тем, что позволяет "тыкать" или "выкать", в зависимости от модальности.
А третье лицо неопределённого пола уже есть, это it. Почему его до сих пор не применяют к небинарным персонам -- непонятно.
Еще Шекспир использовал "they" для единственного числа - тому несложно найти кучу подтверждений (начать с Washington Post и Merriam Webster и продолжить так подробно как хочется самому через гугл). Применение "it" к одушевленным предметам - дерогативно. Поэтому применяем "they" и в некоторых случаях "one" или, если известно более точное местоимение, - то его.
Ну а Ломоносов в свое время писал что-нибудь наподобие такого:
Кто склонность в счастии и доброту являет,
Тот счастие себе недвижно утверждает.
Всяк чувствует в тебе и хвалит обое,
И небо чаемых покажет сбытие.
Но это же не означает, что и сейчас в быту стоит так же писать.
Обычный аргумент против singular "they" -> что это новояз. К вашему аргументу нужно приводить статистику того, что это регулярно использовалось в течение долгого времени - и это так (тоже можно много гуглить). Использовалось ли это так же часто как и в последние лет 5? Разумеется нет. Но это абсолютно нормальная лингвистическая конструкция, которая получила, условно, второе рождение, ибо появилась необходимость.
ибо появилась необходимость
Серьёзно? Ну-ну.
Ок. Каким образом вы будете говорить о лице неопределенного пола? Пример: "I hear that Alex is a software engineer, but I never met them." В данном примере, мы просто не знаем мужчина, женщина или небинарная личность Alex. Раньше, по умолчанию, сказали бы "he". Можно сказать "hе or she" (что на мой взгляд длинновато). Можно попытаться сконструировать предложение без использования местоимения. А можно использовать "them".
Тот факт, что мы стали обращать внимание на то что использование "he" по умолчанию - это не очень - явило собой необходимость более частого употребления singular they. Небинарность - лишь отдельный частный случай, когда использование "he or she" является неоптимальным вариантом.
"I hear that Alex is a software engineer, but I never met them."
В случае именно неизвестного пола (то есть это конкретно я не знаю пол) я бы использовал him по умолчанию.
Сейчас это считает неуместным и нетактичным (внутри определенной культурной, географической, социальной страты). Вы можете не соглашаться, но достаточно много людей считает так.
Так мы от грамматики перешли к вопросу "А судьи кто?"
Не вижу логики. Я обращаюсь к вам на "вы", но с маленькой буквы. Это мой выбор. Мог на "Вы", но я считаю это моветоном (однако уже случалось и не раз в моей жизни, когда это считали неуважением). А мог на "ты". И это в русском языке - фамильярность.
Хотя все три варианта грамматически корректны. Вопрос о том, какой "стиль" использовать в каком контексте, в какой среде, в каком географическом месте - и т. д.
Слабаки, я использовала ИТ для мужчин и женщин)))
Аргумент так себе. Он везде так писал или иногда для рифмы или по случаю? Просто если уж ив договариваемся так писать чтобы определённой группе людей так будет приятнее работать с нашим кодом, то причём тут шекспир? Ещё можно пример привести, что вот в Коране Аллах о себе в основном говорит "мы" тоже, а он между прочим един и тп. Применение it дерогативно? Может проще договориться, что оно более не дерогативно, как стало со словом queer? Как по мне так лучше придумать какое-то новое слово, но раз уж устоялось это - так пусть. Просто Шекспир тут не при чем ведь. Не использовал бы он, все равно ж требовали бы.
‘queer adjective 1. Homosexual. Derogatory from the outside, not from within. US, 1914′
(The Concise New Partridge Dictionary of Slang, p. 524)
Важно то, откуда исходит инициатива. Многим людям более приятно использование "they" (не всем, однако это отдельный разговор). Никогда не слышал о том, чтобы использовать "it" - за исключением людей, кто действительно хочет подчеркнуть "отсутствие души".
Потому что ИТ это оно, а они это она или он, то они себя чувствуют в рамках мужских нормативов то в женских. В нормальном варианте - тащу шкаф в угол, чтобы помыть пол - я мужик, развешивают платья - я девочка. Но те кто сообщает о себе в первом разговоре или пишет в соцсетях о себе в статусе Они/им, - это как правило пустые бесталанный люди которым больше нечем выебнутся
Ну да, главное, стиль соблюсти... А софт все кривее и кривее.
Хотелось бы вот спросить у гугла, как можно обнаружить вирус в hello world на плюсах... Но слишком хорошо спрятались за своими гайдами
20 лет назад - может быть. Сейчас для этих целей есть другие инструменты. И при этом софт всё кривее и кривее ))
Да вообще да. Они называются статические анализаторы и варнинги (а иногда даже ошибки) компилятора. И ваши притянутые за одно место аргументы - лишнее тому подтверждение
По скобкам - это вообще придурь. Такие ошибки может совершать только абсолютно тупой человек. Сравнивать бул с true или false - тоже. Реальный невысосанный пример - это "вызов" макроса. Но батенька, если вы профессионал, то должны уже усвоить, что баловаться макросами в плюсах нельзя. А если вам прям очень приспичило, то вы знаете, как оформить макрос, чтобы он не выстрелил.
Судя по второму примеру, вы вообще плохо знаете, что такое плюсы. Ибо тут чистая ошибка компилятора в обоих случаях, а вы тут про сложнейшие тесты заливаете. Слегка поржал, да. попробуйте проверить сами.
error C2664: 'void DrawFigure(int,int,Shape,Color)': cannot convert argument 3 from 'Color' to 'Shape'
И я не сомневаюсь, что подобных примеров у вас тьма, но может лучше научиться писать нормальный код, чем следовать непонятным ритуалам? Я прекрасно знаю те немногие примеры, которые 20 лет назад могли давать возможность пострелять по ногам и для которых были свои гайды. Но процитирую изначальный пост - это было 20 лет назад.
А еще уставший или не выспавшийся. Они встречаются гораздо чаще, чем вам кажется.
Я перманентно так, но ни одной подобной ошибки не совершил
Тоже хороший пример. Поэтому, кстати, во многих кодинг гайдах тоже запрещают макросы без специальной на то необходимости, вместо них предписывая использовать const, constexpr, inline-функции и т.д.
Не тоже, а единственный более-менее подходящий. Это не в кодинг-гайдах, а прямо в той самой книге по плюсам, которая должна изучаться сразу после кернигана и ритчи. Надо просто плюсы не по ютубу изучать.
Я-то знаю. Но код в проекте может писать джун. Или свитчер из другого языка. И дальше вся надежда только на то, что такое поймают на код-ревью и заставят переписать по-нормальному. А могут и не поймать - по невнимательности, или из-за спешки, или еще как. Так что чем больше возможностей минимизировать человечески фактор и поймать проблему на ранних этапах, тем лучше для всех. Именно поэтому и добавляют правила стайл-гайда в линтер, которые не дает смержить то, что их явно нарушает.
Как писать макросы, спрашивают у джуна на собеседовании. Изучается в числе основ языка. Джун с отсутствием этих знаний - даже ещё не джун.
Интересно. Точно помню, что года там три-четыре назад MSVC такое пропускал. Сейчас уже починили.Но с любом случае, с простыми энамами по сравнению с класс енамами проблемы все равно есть - и неявные касты к инту, и протекание в общий скоуп, и все это тоже увеличивает вероятность ошибок.
Ага. называется, на 146% не прав, но всё равно как-нибудь отбрехаюсь. Не получится. Все компиляторы, и даже древние, дают ошибку на этот кейс. Compller Explorer в помощь. Проблемы с энамами есть, но они соверщенно другие. С самим определением энама всё в порядке, проблема в людях, которые где-то что-то как-то слышали, но не хотят думать, а просто тупо следуют ритуалу. Энам классы "появились" просто потому, что какие-то недумающие люди не очень умели юзать обычные. Заметьте, гайды никак не помогли. А вообще смешно читать, про эту мелочь, когда в C на уровне стандарта есть неявное приведение указателей из void к любому типу, и никто не стонет
Ахахахаха. Где-то это я уже слышал. "Зачем программисты делают в коде баги? Пусть научатся писать сразу без багов". Вот только почему-то это до их пор никому не удалось - всю жизнь писать код, не сделав ни одного бага. Причем баги по невнимательности (а речь именно про них) допускают и разработчики с огромным опытом и прекрасным знанием своих инструментов. Именно по невнимательности. Человеческий фактор.
Ну да. Тут проще всего броситься в другую крайность. Типа "зачем думать, это же всё равно бесполезно". Нет, думать всё же полезно. Да, это не избавит от ошибок. А тупое следование ритуалам может породить и отвратительный код, и ещё более серьёзные баги. Я в десятый раз пишу: "баги по невнимательности" 20 лет отлавливают сами компиляторы и статические анализаторы, и ничего более.
Поэтому повторюсь: чем больше возможностей минимизировать человечески фактор и поймать проблему на ранних этапах, тем лучше для всех. Именно поэтому и добавляют правила стайл-гайда в линтер, которые не дает смержить то, что их явно нарушает.
Поэтому повторюсь, ритуалы никак не влияют на отлов проблем на ранних этапах, а только замедляют написание кода. Не зря гугель убрал про здравый смысл. Его уже нет. Пишешь hello world, компилируешь - а там, оказывается, уже вирус )))
И никакой статический анализатор и IDE вам это не поймают
V640. Code's operational logic does not correspond with its formatting. :-)
Ну и в компиляторах оно теперь тоже есть:
Также явно обозвали стиль именования «маленькие буквы; слова через подчёркивание»: теперь это называется змеиный стиль.
Snake case не они изобрели же. Он существует ничуть не меньше чем верблюд и шашлычный формат
Что обозначает буква k в именах перечислений?
Это обозначение того, что это constexpr . Не совсем логично и из внутренний кухни Гугла. Нацелено на то, чтобы при любом взгляде на что угодно сразу видеть, что есть constexpr а что нет - и это было распространено и на enum и на `enum class`.
Не обязательно constexpr, это (исходно) для const у них стандартный префикс https://google.github.io/styleguide/cppguide.html#Constant_Names.
Дельное замечание. Причина моей оговорки - что почти всегда в code review (исходя из моего опыта в гугле) тебе порекомендуют из const - сделать constexpr за исключением некоторых случаев, где это либо невозможно, либо некорректно.
(разумеется, я о тех случаях, где объявляются переменные или, как заметил автор треда, члены `enum class`a).
Это пошло из WebKit и намного раньше C++11 с constexpr. Это венгерская нотация огрызков - любая константа начинается с k, потому что c уже занята для char.
KDE-шники везде пихали K к своим классам, которые в основном были обёртками над Qt-классами с их Q. Но с k в константах замечены не были.
https://github.com/KDE/kde1-kdelibs/blob/master/kdecore/kpixmap.h#L26-L28
https://github.com/KDE/kde1-kdelibs/blob/master/khtmlw/htmldata.cpp#L28
https://github.com/KDE/kde1-kdelibs/blob/master/khtmlw/htmltoken.cpp#L47-L49
У implicit_cast ещё много применений, кроме видимости.
Скажем тернарный оператор с разными типами
A* a = foo ? new B() : new C(), где B и С наследники А, без приведения B* к А* компилятор не поймет тип выражения справа от =.
Руководство Google по стилю в C++: 2019 — 2024