Все мы при написании кода пользуемся правилами оформления кода. Иногда изобретаются свои правила, в других случаях используются готовые стайлгайды. Однако, любой стайлгайд со временем корректируется и дорабатывается: иногда этому способствуют обновление стандартов языка, иногда меняются тенденции.
В статье приведены изменения Руководства Google по стилю в C++ за 5 лет: с 2019 по 2024.
Краткое содержание изменений:
+ C++20 - NULL + концепты - #pragma + constinit - std:hash + consteval - u8 + аргументы-ссылки - ENUM_VALUE_NAME + повесточка и "they" в единственном числе - здравый смысл
Изменения в «Руководстве» по стилю можно разделить на три направления:
1. Переход на C++20
Основной стандарт языка в Руководстве теперь от 20-го года и отныне код должен соответствовать C++20. Однако, это совсем не означает, что можно использовать новые возможности.
В частности, если планируется портирование кода для различных платформ, то следует оценить целесообразность применения новых возможностей как C++17, так и C++20 и, в некоторых случаях, даже отказаться от них. Но в любом случае создаваемый код должен корректно работать в C++20 (и в качестве примера смотрите про запрет префикса u8 ниже).
Если же C++20 допустим в проекте, то «Руководство» предлагает использовать новые возможности:
— Используйте constinit и consteval
Заметим, что constinit и раньше предлагался к использованию, но только в форме атрибута ABSL_CONST_INIT от внешней кодовой базы. Теперь constinit уже официально внесён в стандарт и рекомендуется к применению.
Что касается consteval, то если вы желаете чтобы функция вычислялась только при компиляции, то лучше применять consteval. А если единственное желание это сделать функцию встраиваемой — то не применять.
— Разрешён оператор трёхстороннего сравнения (оператор «космокорабль», эквивалентности). Его рекомендуется использовать только в тех случаях, когда для двух значений некоторого типа соотношение больше/меньше является очевидным, ясным и единственным. И если всё это выполняется, то рекомендуется определить два оператора: == и <=>. Эти определения должны быть непротиворечивы в части сравнения на равенство. А от остальных операторов сравнения следует избавиться.
С другой стороны, если отношение больше/меньше не такое уж очевидное, или возможно несколько вариантов, то не определяйте оператор <=>.
— Добавилась возможность назначенной инициализации («Designated_initializers»). Назначенная инициализация ранее считалась нестандартным расширением и не рекомендовалась к использованию. После появления в стандарте её можно использовать, но только в виде, совместимом с C++20. Например:
struct Point {
float x = 0.0;
float y = 0.0;
float z = 0.0;
};
Point p = {
.x = 1.0,
.y = 2.0,
// z будет 0.0
};
Концепты и Ограничения. В «Руководстве» разрешили использовать концепты с ограничениями и сразу сделали дополнительный раздел о том, что такое концепты/ограничения, что можно с ними делать, что нежелательно, какие здесь плюсы и минусы. В целом, всё соответствует логике, но, например, такая форма записи:
template<Concept T>не рекомендуется.
И вообще, «Руководство» призывает «используйте концепты в разумных количествах, без фанатизма».
2. От чистого C в более безопасный C++
В этой части «Руководство» постаралось перенять хорошие практики, которые ранее были запрещены, и запретить что-то совсем устаревшее.
Ссылочные выходные параметры: одно из явных изменений связано с использованием ссылочных аргументов для выдачи результата (как выходные параметры). Если в ранних версиях «Руководства» ссылки могли использоваться только как входные параметры (в виде константных ссылок), то теперь ссылки используются и для возврата значений в обязательных (т.е. не опциональных) параметрах. Обычные указатели тоже не забыты и всё ещё применяются для возврата значений в опциональных параметрах (для которых допустимо передавать nullptr). И параллельно для опциональных параметров предлагается использовать std::optional — это такая современная альтернатива.
#pragma объявлена недопустимой и не должна использоваться, т.к. это нестандартное расширение. Причём в ранних версиях «Руководства» про неё упоминалось вскользь и только в разделе про программирование под Windows. Теперь это стало общим правилом. С учётом запрета на #pragma once и постепенному переходу к правильно выровненным данным (и сомнительной полезности #pragma pack в этом случае) это может быть логичным решением. Особенно учитывая построение под различные платформы и с применением разных компиляторов.
NULL — конечно же, он тоже теперь под запретом. Если раньше в «Руководстве» ещё были упоминания про C++03 и допускалось использование NULL для совместимости, то теперь есть только nullptr.
раздел std::hash вообще удалён из «Руководства» — видимо, чтобы даже мыслей не было про собственные пользовательские специализации. В целом, наверное это правильное движение, так как создание нормальной хэш-функции для специфических типов может быть совсем нетривиальной задачей.
использование #include-ов ещё больше регламентировано. Во-первых, рекомендуется подключать все используемые заголовочные файлы, не полагаться на вложенные #include-ы (ситуация, когда один заголовочный файл включает другой, тот включает третий и т.д.) и это должно сделать использование заголовочных файлов более самодостаточным и безопасным. Вообще это может быть здравой идеей, но далеко не всегда: например, если вы используете библиотеку, у которой общий заголовочный файл со списком #include-ов (это очень частое решение), то вместо одного общего файла как-бы рекомендуется прописывать весь список — и это ну очень неоднозначное решение.
Также про включение заголовочных файлов есть интересная рекомендация стараться указывать имя файла именно в кавычках (а угловые скобки использовать только по явной необходимости; системные файлы являются такой необходимостью). Такой подход может быть, наверное, полезным, так как пути системных заголовочных файлов всё равно будут использованы в поиске, а возможное упрощение может снизить количество ошибок.
В плане безопасного применения C++ есть тоже подвижки:
enum class: теперь энумераторы объявляются в форме «с областью видимости»:
enum class UrlTableError { ... } и это может быть полезным в больших кодовых базах.std::unique_ptr постепенно заменяет обычные указатели, и такой подход тоже может сделать код более безопасным.
Пока эти изменения не указаны как явные рекомендации в тексте, но примеры кода уже обновлены (т.е. существующий код пока можно не переписывать, однако скоро придётся).
constexpr string_view предлагается как предпочтительный тип для глобальных или статических строковых констант. Символьный массив или указатель на первый символ строкового литерала тоже пока ещё допустимы, но направление движения уже в сторону средств C++.
std::bit_cast рекомендуется для приведения типов (ранее рекомендовалось использование absl::bit_cast) и в свете увеличивающегося количества UB это логичное требование.
absl::implicit_cast рекомендуется для приведения типов вверх по иерархии классов. Оно, конечно, и само приводится, но так безопаснее (возможно) и легче ищется по коду (это более вероятно).
переменные thread_local используются всё чаще и в «Руководстве» расширено описание по использованию: расписано как их применять, на что обратить внимание (спойлер: на порядок переменных и их деструкторы: потоки могут создаваться и завершаться часто, деструкторы вызываются постоянно, и для корректной работы всё должно быть в правильном порядке), и инициализировать их в ряде случаев нужно как constinit. В общем, «Руководство» проводит разъяснительную работу и заботится о безопасности кода.
префикс u8 умудрился попасть под запрет: сейчас по возможности избегайте его использования. Префикс u8 стал «нехорошим» после того, как стандартизаторы многое перекроили и теперь в разных стандартах при использовании префикса u8 создаются массивы из символов разного типа: где-то это char[], где-то char8_t[]. Так как есть подозрение, что в следующем стандарте опять могут что-то поменять, то решили, что лучше без префикса.
3. Именование, Комментарии, Пунктуация
В этом направлении «Руководство» тоже обновилось. В целом это ожидаемо, так как основная цель «правильного» написания кода это облегчить его чтение и поддержку.
Именование постепенно уходит от привычек чистого C:
— имена в перечислениях в прописном регистре (ENUM_NAME) теперь применять нельзя. Нужно использовать именование в стиле обычной константы: kEnumName.
— начинается «выдавливание» макросов препроцессора из кода. Пока делаются мягкие воздействия: в макросах препроцессора рекомендуется использовать название проекта, например так:
#define MYPROJECT_ROUND(x)
— добавились правила именования концептов.
Расстановку пробелов и переводов строки переписали и сделали «алгоритм». Раньше это был набор примеров, теперь всё формализовали и ввели понятия: оператор, итерация, лексема, здесь ставим пробел, а здесь перевод строки. В общем намудрили, но, похоже, это вынужденно, так как когда в блоке условия пишется много разного:
} else if (int a = f(); a != 3) {
одними примерами уже не обойтись. К счастью, примеры пока ещё тоже остались: можно по ним изучать пунктуационную мысль.
Также явно обозвали стиль именования «маленькие буквы; слова через подчёркивание»: теперь это называется змеиный стиль.
Повесточка начинает влиять на код. В целом, это было очевидно, что желание не обидеть доберётся и до оформления кода. Вот теперь добралось:
Добавлен раздел про «Инклюзивный Язык», в котором нам объясняют, что использование терминов «белый список» и «чёрный список» не приветствуется, также как и многих других. И вместо местоимений «он» или «она» нужно использовать ангийский «they» или «their» в качестве местоимения единственного числа (видимо, на манер устаревшего местоимения «онЕ»).
Минус Здравый Смысл: к сожалению, был выкинут заключительный раздел, где рекомендовали руководствоваться здравым смыслом и придерживаться постоянства в кодировании. Выкинут целиком. Вот так.
Итог:
Идёт постепенный разворот от чистого C в сторону безопасного и толерантного C++. И «Руководство» есть отражение этого.Ссылки на версии «Руководства»:
Руководство Google по стилю в C++ 2019: Серия статей на Хабре
Руководство Google по стилю в C++ 2024
Комментарии (36)
9241304
07.09.2024 16:50Ну да, главное, стиль соблюсти... А софт все кривее и кривее.
Хотелось бы вот спросить у гугла, как можно обнаружить вирус в hello world на плюсах... Но слишком хорошо спрятались за своими гайдами
UranusExplorer
07.09.2024 16:50+1Ну да, главное, стиль соблюсти...
Стиль кодирования предназначен не только для улучшения читаемости, но и для защиты от ряда ошибок по невнимательности.
9241304
07.09.2024 16:5020 лет назад - может быть. Сейчас для этих целей есть другие инструменты. И при этом софт всё кривее и кривее ))
UranusExplorer
07.09.2024 16:50+220 лет назад - может быть. Сейчас для этих целей есть другие инструменты.
Да вообще нет. Например, в стиле кодирования часто требуют ставить
{}даже для однострочных блоков.
Потому что очень популярная ошибка, когда у вас есть код типаif (resultSuccess == true) doSomething();а потом человек хочет добавить какое-нибудь еще одно действие, то по невнимательности сделает
if (resultSuccess == true) logger.LogEvent(...); doSomething();со всеми вытекающими. И никакой статический анализатор и IDE вам это не поймают - в лучшем случае поймают тесты, если они у вас есть, регулярно обновляются и покрывают сто процентов кейсов. А если бы изначально
doSomething()было внутри явного{...}скоупа, то такая ошибка гораздо менее вероятна.Опять же, стандарт кодирования может помогать анализаторам находить ошибки. В плюсах, например, есть
enum, а естьenum class. Современные coding guides часто запрещают использовать первое в пользу второго, потому что если у вас есть, например, enum'ы Shape и Color, и функция типаDrawFigure(int X, int Y, Shape shape, Color color), то перепутав местами 3 и 4 аргумент вы получите полностью корректный код с точки зрения компилятора и анализатора (а IDE так вообще сама может вам его предложить), хотя на самом деле там будет баг. И этот баг вы в лучшем случае отловите только тестами, и то, если тесты покрывают абсолютно все возможные сочетания Shape и Color (а 100% code coverage от анализатора у вас может быть и без этого, в зависимости от внутренней логики). В то время как использовав enum class вместо простого enum по рекомендации кодинг-гайдов, такую ошибку компилятор вам поймает еще на этапе компиляции.И таких примеров очень и очень много.
9241304
07.09.2024 16:50Да вообще да. Они называются статические анализаторы и варнинги (а иногда даже ошибки) компилятора. И ваши притянутые за одно место аргументы - лишнее тому подтверждение
По скобкам - это вообще придурь. Такие ошибки может совершать только абсолютно тупой человек. Сравнивать бул с true или false - тоже. Реальный невысосанный пример - это "вызов" макроса. Но батенька, если вы профессионал, то должны уже усвоить, что баловаться макросами в плюсах нельзя. А если вам прям очень приспичило, то вы знаете, как оформить макрос, чтобы он не выстрелил.
Судя по второму примеру, вы вообще плохо знаете, что такое плюсы. Ибо тут чистая ошибка компилятора в обоих случаях, а вы тут про сложнейшие тесты заливаете. Слегка поржал, да. попробуйте проверить сами.
error C2664: 'void DrawFigure(int,int,Shape,Color)': cannot convert argument 3 from 'Color' to 'Shape'
И я не сомневаюсь, что подобных примеров у вас тьма, но может лучше научиться писать нормальный код, чем следовать непонятным ритуалам? Я прекрасно знаю те немногие примеры, которые 20 лет назад могли давать возможность пострелять по ногам и для которых были свои гайды. Но процитирую изначальный пост - это было 20 лет назад.
UranusExplorer
07.09.2024 16:50Такие ошибки может совершать только абсолютно тупой человек.
А еще уставший или не выспавшийся. Они встречаются гораздо чаще, чем вам кажется.
Реальный невысосанный пример - это "вызов" макроса.
Тоже хороший пример. Поэтому, кстати, во многих кодинг гайдах тоже запрещают макросы без специальной на то необходимости, вместо них предписывая использовать const, constexpr, inline-функции и т.д.
Но батенька, если вы профессионал, то должны уже усвоить, что баловаться макросами в плюсах нельзя
Я-то знаю. Но код в проекте может писать джун. Или свитчер из другого языка. И дальше вся надежда только на то, что такое поймают на код-ревью и заставят переписать по-нормальному. А могут и не поймать - по невнимательности, или из-за спешки, или еще как. Так что чем больше возможностей минимизировать человечески фактор и поймать проблему на ранних этапах, тем лучше для всех. Именно поэтому и добавляют правила стайл-гайда в линтер, которые не дает смержить то, что их явно нарушает.
Слегка поржал, да. попробуйте проверить сами.
Интересно. Точно помню, что года там три-четыре назад MSVC такое пропускал. Сейчас уже починили.
Но с любом случае, с простыми энамами по сравнению с класс енамами проблемы все равно есть - и неявные касты к инту, и протекание в общий скоуп, и все это тоже увеличивает вероятность ошибок.но может лучше научиться писать нормальный код
Ахахахаха. Где-то это я уже слышал. "Зачем программисты делают в коде баги? Пусть научатся писать сразу без багов". Вот только почему-то это до их пор никому не удалось - всю жизнь писать код, не сделав ни одного бага. Причем баги по невнимательности (а речь именно про них) допускают и разработчики с огромным опытом и прекрасным знанием своих инструментов. Именно по невнимательности. Человеческий фактор.
Поэтому повторюсь: чем больше возможностей минимизировать человечески фактор и поймать проблему на ранних этапах, тем лучше для всех. Именно поэтому и добавляют правила стайл-гайда в линтер, которые не дает смержить то, что их явно нарушает.
9241304
07.09.2024 16:50А еще уставший или не выспавшийся. Они встречаются гораздо чаще, чем вам кажется.
Я перманентно так, но ни одной подобной ошибки не совершил
Тоже хороший пример. Поэтому, кстати, во многих кодинг гайдах тоже запрещают макросы без специальной на то необходимости, вместо них предписывая использовать const, constexpr, inline-функции и т.д.
Не тоже, а единственный более-менее подходящий. Это не в кодинг-гайдах, а прямо в той самой книге по плюсам, которая должна изучаться сразу после кернигана и ритчи. Надо просто плюсы не по ютубу изучать.
Я-то знаю. Но код в проекте может писать джун. Или свитчер из другого языка. И дальше вся надежда только на то, что такое поймают на код-ревью и заставят переписать по-нормальному. А могут и не поймать - по невнимательности, или из-за спешки, или еще как. Так что чем больше возможностей минимизировать человечески фактор и поймать проблему на ранних этапах, тем лучше для всех. Именно поэтому и добавляют правила стайл-гайда в линтер, которые не дает смержить то, что их явно нарушает.
Как писать макросы, спрашивают у джуна на собеседовании. Изучается в числе основ языка. Джун с отсутствием этих знаний - даже ещё не джун.
Интересно. Точно помню, что года там три-четыре назад MSVC такое пропускал. Сейчас уже починили.Но с любом случае, с простыми энамами по сравнению с класс енамами проблемы все равно есть - и неявные касты к инту, и протекание в общий скоуп, и все это тоже увеличивает вероятность ошибок.
Ага. называется, на 146% не прав, но всё равно как-нибудь отбрехаюсь. Не получится. Все компиляторы, и даже древние, дают ошибку на этот кейс. Compller Explorer в помощь. Проблемы с энамами есть, но они соверщенно другие. С самим определением энама всё в порядке, проблема в людях, которые где-то что-то как-то слышали, но не хотят думать, а просто тупо следуют ритуалу. Энам классы "появились" просто потому, что какие-то недумающие люди не очень умели юзать обычные. Заметьте, гайды никак не помогли. А вообще смешно читать, про эту мелочь, когда в C на уровне стандарта есть неявное приведение указателей из void к любому типу, и никто не стонет
Ахахахаха. Где-то это я уже слышал. "Зачем программисты делают в коде баги? Пусть научатся писать сразу без багов". Вот только почему-то это до их пор никому не удалось - всю жизнь писать код, не сделав ни одного бага. Причем баги по невнимательности (а речь именно про них) допускают и разработчики с огромным опытом и прекрасным знанием своих инструментов. Именно по невнимательности. Человеческий фактор.
Ну да. Тут проще всего броситься в другую крайность. Типа "зачем думать, это же всё равно бесполезно". Нет, думать всё же полезно. Да, это не избавит от ошибок. А тупое следование ритуалам может породить и отвратительный код, и ещё более серьёзные баги. Я в десятый раз пишу: "баги по невнимательности" 20 лет отлавливают сами компиляторы и статические анализаторы, и ничего более.
Поэтому повторюсь: чем больше возможностей минимизировать человечески фактор и поймать проблему на ранних этапах, тем лучше для всех. Именно поэтому и добавляют правила стайл-гайда в линтер, которые не дает смержить то, что их явно нарушает.
Поэтому повторюсь, ритуалы никак не влияют на отлов проблем на ранних этапах, а только замедляют написание кода. Не зря гугель убрал про здравый смысл. Его уже нет. Пишешь hello world, компилируешь - а там, оказывается, уже вирус )))
mayorovp
07.09.2024 16:50И никакой статический анализатор и IDE вам это не поймают
V640. Code's operational logic does not correspond with its formatting. :-)
Ну и в компиляторах оно теперь тоже есть:
UranusExplorer
07.09.2024 16:50V640. Code's operational logic does not correspond with its formatting. :-)
Ну и в компиляторах оно теперь тоже есть:
Это если только после изменения человек не сделал Ctrl-K + Ctrl-F (или аналог из его IDE), что у многих доведено до автоматизма :)
domix32
07.09.2024 16:50+9Также явно обозвали стиль именования «маленькие буквы; слова через подчёркивание»: теперь это называется змеиный стиль.
Snake case не они изобрели же. Он существует ничуть не меньше чем верблюд и шашлычный формат
alexejisma
07.09.2024 16:50Что обозначает буква k в именах перечислений?
Anton_Menshov
07.09.2024 16:50Это обозначение того, что это
constexpr. Не совсем логично и из внутренний кухни Гугла. Нацелено на то, чтобы при любом взгляде на что угодно сразу видеть, что естьconstexprа что нет - и это было распространено и наenumи на `enum class`.
hiewpoint
07.09.2024 16:50+2Не обязательно constexpr, это (исходно) для const у них стандартный префикс https://google.github.io/styleguide/cppguide.html#Constant_Names.
Anton_Menshov
07.09.2024 16:50+1Дельное замечание. Причина моей оговорки - что почти всегда в code review (исходя из моего опыта в гугле) тебе порекомендуют из
const- сделатьconstexprза исключением некоторых случаев, где это либо невозможно, либо некорректно.(разумеется, я о тех случаях, где объявляются переменные или, как заметил автор треда, члены `enum class`a).
sergio_nsk
07.09.2024 16:50+4Это пошло из WebKit и намного раньше C++11 с
constexpr. Это венгерская нотация огрызков - любая константа начинается сk, потому чтоcуже занята для char.UranusExplorer
07.09.2024 16:50Огрызки свой WebKit форкали из KHTML, там тоже так?
В коде хромиума, кстати, остались рудименты оттуда в виде префикса "K" (заглавной), например класс KURL.
sergio_nsk
07.09.2024 16:50KDE-шники везде пихали
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
mentin
07.09.2024 16:50У
implicit_castещё много применений, кроме видимости.Скажем тернарный оператор с разными типами
A* a = foo ? new B() : new C(), где B и С наследники А, без приведения B* к А* компилятор не поймет тип выражения справа от =.
Keeper10
Лучше бы вернули thou/thee в пару к you.
mayorovp
Чем лучше? Это ж второе лицо, а нужно третье...
Keeper10
Тем, что позволяет "тыкать" или "выкать", в зависимости от модальности.
А третье лицо неопределённого пола уже есть, это it. Почему его до сих пор не применяют к небинарным персонам -- непонятно.
Anton_Menshov
Еще Шекспир использовал "they" для единственного числа - тому несложно найти кучу подтверждений (начать с Washington Post и Merriam Webster и продолжить так подробно как хочется самому через гугл). Применение "it" к одушевленным предметам - дерогативно. Поэтому применяем "they" и в некоторых случаях "one" или, если известно более точное местоимение, - то его.
KanuTaH
Ну а Ломоносов в свое время писал что-нибудь наподобие такого:
Но это же не означает, что и сейчас в быту стоит так же писать.
Anton_Menshov
Обычный аргумент против singular "they" -> что это новояз. К вашему аргументу нужно приводить статистику того, что это регулярно использовалось в течение долгого времени - и это так (тоже можно много гуглить). Использовалось ли это так же часто как и в последние лет 5? Разумеется нет. Но это абсолютно нормальная лингвистическая конструкция, которая получила, условно, второе рождение, ибо появилась необходимость.
KanuTaH
Серьёзно? Ну-ну.
Anton_Menshov
Ок. Каким образом вы будете говорить о лице неопределенного пола? Пример: "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" является неоптимальным вариантом.
Keeper10
В случае именно неизвестного пола (то есть это конкретно я не знаю пол) я бы использовал him по умолчанию.
Anton_Menshov
Сейчас это считает неуместным и нетактичным (внутри определенной культурной, географической, социальной страты). Вы можете не соглашаться, но достаточно много людей считает так.
Keeper10
Так мы от грамматики перешли к вопросу "А судьи кто?"
Anton_Menshov
Не вижу логики. Я обращаюсь к вам на "вы", но с маленькой буквы. Это мой выбор. Мог на "Вы", но я считаю это моветоном (однако уже случалось и не раз в моей жизни, когда это считали неуважением). А мог на "ты". И это в русском языке - фамильярность.
Хотя все три варианта грамматически корректны. Вопрос о том, какой "стиль" использовать в каком контексте, в какой среде, в каком географическом месте - и т. д.
MissPeace
Слабаки, я использовала ИТ для мужчин и женщин)))
c0r3dump
Аргумент так себе. Он везде так писал или иногда для рифмы или по случаю? Просто если уж ив договариваемся так писать чтобы определённой группе людей так будет приятнее работать с нашим кодом, то причём тут шекспир? Ещё можно пример привести, что вот в Коране Аллах о себе в основном говорит "мы" тоже, а он между прочим един и тп. Применение it дерогативно? Может проще договориться, что оно более не дерогативно, как стало со словом queer? Как по мне так лучше придумать какое-то новое слово, но раз уж устоялось это - так пусть. Просто Шекспир тут не при чем ведь. Не использовал бы он, все равно ж требовали бы.
Anton_Menshov
Важно то, откуда исходит инициатива. Многим людям более приятно использование "they" (не всем, однако это отдельный разговор). Никогда не слышал о том, чтобы использовать "it" - за исключением людей, кто действительно хочет подчеркнуть "отсутствие души".
MissPeace
Лол да не я использую ИТ для скщество. Это существо провалило проект. Это существо имеет чудесный эстетический вкус и большой опыт.
MissPeace
Потому что ИТ это оно, а они это она или он, то они себя чувствуют в рамках мужских нормативов то в женских. В нормальном варианте - тащу шкаф в угол, чтобы помыть пол - я мужик, развешивают платья - я девочка. Но те кто сообщает о себе в первом разговоре или пишет в соцсетях о себе в статусе Они/им, - это как правило пустые бесталанный люди которым больше нечем выебнутся