Home / Questions / 22360
Accepted
AlejandroMedina
Asked: 2020-09-02 17:03:11 +0800 CST 2020-09-02 17:03:11 +0800 CST

Использование Ñ в именах переменных

  • 772

Традиционно рекомендация для имен переменных и методов в языках программирования всегда заключалась в том, чтобы не использовать специальные символы, включая Ñ.

По традиции я до сих пор называю переменные "год" "аннио", даже другие программисты используют "ано", "анно", "анхо", "год" и т. д.; хотя в настоящее время Visual Studio позволяет без проблем вызывать переменную «Год» при компиляции.

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

c#

5 Answers

  1. Best Answer

    Мне было интересно, что мешает мне использовать слово «год», и я хотел узнать ваше мнение о нем: хорошее, плохое и безобразное; любое мнение или комментарий по этому поводу будут мне полезны.

    1) Работа в интернациональной команде.

    Когда вы работаете в интернациональной команде, использование каких персонажей может стать кошмаром для других членов команды; не все клавиатуры имеют одинаковую возможность доступа (например) к нашей любимой N с гребенкой; поэтому, если вы используете эту клавиатуру:

    И ваш североамериканский коллега использует это:

    У вашего партнера будет проблема с доступом к Ñ. А если вы работаете с компьютерами, у которых очень разные алфавиты, проблема возрастает в геометрической прогрессии:

    int 入玉口千 = 0xFf800000;
int 人王ロ干 = 0xF8000000;

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

    Decimal año = 2000; // 365 días
Decimal ano = 2016; // Parte de mi anatomía

    Для меня разница между двумя вещами очень очевидна, возможно, у других сотрудников из других стран она не так очевидна.

    bool flag = false; // это не является необходимым

    Я никогда не узнаю, что хотел сказать мой коллега Павлов Провоторов.

    public void Iͬͩͩ̽ͦ̍҉̣͙ņ̨̠̩͈̰͎̹̼̎̊͑̌̀vͪ͐ͮ̒ͣ͒͡͏̠̤̱̪̥ợ̟͔ͭ̃͌c͙̣̱̏̿ͯ̓̅̋͛a̵̝̲͚̭̗ͬ̊ͅ_̷̱̻̤̪̝̥̠͉̂̐͊ͣ͡͝ͅâ̬̱̳̮͆ͭ̕͢ͅl̟͕̳̣ͯͦ̎ͯ̄ͩ͗ͯ̕̕͞_̽ͪ̇ͫ̆҉̧̱͚̻̝̠d̮̗̜͈̝̩̦͆̓̑͐e͂҉̩̩͓͠m̛̠̣͈̠̩̂̂͋̅ô̧͍͑͌͛n̂͏͙̭i̧͉̋ͤ̏̐̍͊͘o̶͕̹̳̟͇͇̝͉ͮͩ͋͆()

    Я даже не хочу думать, что может эта функция.

    bool ? = check_error();
if (?) { // shit happens

    Кому-то это покажется забавным, мне это кажется безвкусицей .

    2) Товарищи чрезмерно привязаны к правильности.

    Я сталкивался с проблемами, подобными той Ñ, когда коллеги-математики писали такой код:

    double π = 3.14159265;

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

    Ну, а IDE помогают решить эту проблему, допустим, у вас есть:

    class MathConstants
{
    public const double π = 3.14159265;
    public const double e = 2.71828;
    public const double α = ...
    public const double δ = ...
    public const double φ = ...
    public const double γ = ...
    public const double λ = ...
}

    Можно было бы ожидать, что ввод в IDE выдаст мне список математических констант MathConstants.после точки и таким образом избавит меня от их ввода, но в большинстве IDE, которыми я пользовался в то время, в лучшем случае список неизвестных символов ( или ), я даже использовал версию Eclipse, которая завершала работу (без сохранения измененных файлов!), если я открывал список элементов объекта со странными идентификаторами , поэтому в итоге я изменил код на:.?□

    class MathConstants
{
    public const double Pi              = 3.14159265;
    public const double Euler           = 2.71828;
    public const double Phi             = ...
    public const double EulerMascheroni = ...
    public const double Conway          = ...
}

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

    3) Системы кодирования и управления версиями.

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

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

    Резюме.

    Шрифт Ñ ñ— это лишь верхушка айсберга в несколько более сложной проблеме, связанной с использованием символов Юникода в исходном коде. Эти символы могут вызывать проблемы без существенного улучшения качества кода, поэтому их использование можно считать небольшим улучшением большой проблемы.

    С другой стороны, если мы разрешаем буквы из испанского алфавита, такие как eñe или ce с cedilla ( ç), у нас нет причин запрещать буквы в других языках, что легко перерастает в более серьезные проблемы. Если мы будем работать в интернациональной команде, некоторым программистам будет удобнее программировать на своем языке, и это хорошо для них и плохо для команды (извините, Павлов, я терпеть не могу ваши комментарии на кириллице)... и это не к Упомяните, что в каждой стране могут быть разные клавиатуры или что используемая нами среда разработки может быть не готова к работе с этими символами, или даже эти символы сводят компилятор с ума .

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

    Вывод.

    Я не вижу существенного преимущества в использовании Ñтого или иного экзотического символа в исходном коде, но пока всем удобно работать с таким кодом, я также не вижу причин его запрещать.

    • 50

  2. Это очень обсуждаемый вопрос. У большинства из нас, программистов, действительно есть традиция избегать «странных» (не ASCII) символов в идентификаторах (даже в именах файлов...)

    На стороне «только ASCII»: эта традиция кажется здоровой. Потенциальные конфликты с различными кодировками избегаются при разработке в команде (например, некоторые разработчики используют UTF-8, другие ISO-8859-1, третьи UTF-16...) или даже при компиляции (компилятор должен согласиться с редактором. Это также полезно, когда вы хотите поделиться кодом (фрагментами) или задать вопросы на общедоступных сайтах, которые обрабатываются в основном на английском языке (ТАК, не заходя дальше).[*]

    На стороне «все идет»: мы живем в 2016 году. Большинство языков (среди них C#) без проблем поддерживают идентификаторы с символами Unicode. И Unicode больше не должен быть загадкой ни для какого начинающего программиста, и все программисты на испанском языке должны знать, что когда мы редактируем текстовый файл (возможно, с не-ASCII-символами), мы используем определенную кодировку (и нам всегда приходится решайте сами). вход, не позволяйте нашей операционной системе или нашей IDE делать это за себя). С этой точки зрения использование Юникода в идентификаторах в определенном смысле целесообразно: потому что это заставляет нас быть осознанными и последовательными в кодировках (и знакомиться с Юникодом, если раньше он нам не нравился).для исходного кода.

    Со своей стороны, я не вижу возражений против использования añoв качестве идентификатора в C#. Но если вы это сделаете, и когда я спрошу : «Какую кодировку вы используете для своего исходного кода?» не знаешь что мне ответить, тогда да у нас беда.

    [*] Попутно обратите внимание, что большинство этих аргументов также будут препятствовать использованию символов, отличных от ASCII, не только в идентификаторах, но и в литеральных значениях и даже в комментариях — что кажется слишком ограничительным.

    • 9

  3. Я опаздываю, но я хотел бы внести свой вклад в это дело.

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

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

    Но даже в случае проприетарного кода, разработанного небольшой компанией с одним офисом, где все сотрудники местные, выгодно иметь весь код на английском языке. Что, если за пять лет компания выросла и решит нанять удаленных сотрудников в других уголках планеты? Что, если в Испанию приедет жить англичанин и окажется, что он отличный программист и хочет работать в вашей компании (я сталкивался с этим)? Если код на испанском языке, можно будет нанимать только испаноязычных сотрудников.

    И еще вопрос: если вы хотите вставить часть кода на сайт с просьбой о помощи (будь то оригинальный Stack Overflow или форум поддержки компании) и у вас все на испанском, вам придется каждый раз все переводить время.

    Вот как я это вижу, весь мой код был на 100% на английском языке в течение многих лет, и я обнаружил, что все это является преимуществом. Но я понимаю, что не все в жизни черное или белое, и будут обстоятельства, при которых код обязательно должен быть на испанском по каким-то причинам. В этих случаях я согласен с PaperBirdMaster: я бы избегал любых символов, отличных от ASCII, таких как чума, и писал «год» как «год». Программирование уже достаточно сложно, а инструменты (IDE, репозитории, среды непрерывной интеграции...) уже сами по себе вызывают достаточно проблем, не рискуя проблемами с кодировкой исходных файлов.

    • 9

  4. Краткий ответ: программа всегда на английском языке . Ставьте не «año» и «annio», тем более «ano», а «год».

    Некоторые преимущества:

    • Он более компактен, чем другие языки (« драйвер » vs « драйвер »).
    • Если вы хотите поделиться своим кодом, английский язык является универсальным.
    • Если вы копируете функции на английском языке, чтобы добавить их в свой код, вы экономите на их переводе.
    • Как правило, API-интерфейсы обычно на английском языке, поэтому программирование на одном языке повышает единообразие и удобочитаемость (« загрузка (fileTest) » против « загрузка (testFile) »).
    • К этому сразу привыкаешь.
    • О, и вы избавите себя от хлопот с символами ASCII> 128.
    • 2

  5. Как вы говорите, ограничений с точки зрения C# нет, но есть культурно. Если вы уверены, что ваша рабочая команда всегда будет на испанском языке, вы можете использовать Ñ. Теперь это заставит вас задуматься о том, что делать с акцентами, здесь все становится немного сложнее, поскольку не все хорошо знают использование акцентов, и это может привести к тому, что будут объявлены разные переменные, которым нужны ссылки на них. , объект.

    • 0