Что вы делаете, когда ваше соглашение об именах конфликтует с вашим языком?

14

Ладно, это одна из тех мелочей, которые всегда меня раздражали. Как правило, я не сокращаю идентификаторы, и единственный раз, когда я использую короткий идентификатор (например, i), это узкий цикл. Поэтому меня раздражает, когда я работаю в C ++, и у меня есть переменная, которая должна быть названа, operatorили classя должен обойти ее или использовать аббревиатуру, потому что она заканчивается торчащим. Предостережение: это может случиться со мной непропорционально часто, потому что я много работаю над дизайном языка программирования, где доменные объекты могут отражать понятия в языке хоста и непреднамеренно приводить к конфликтам.

Как бы вы справились с этим? Сокращать? ( op) Misspell? ( klass) Что-то еще? ( operator_)

Джон Перди
источник
7
Помимо пространства имен, возможно, нам следует рассмотреть вопрос об изменении наших соглашений об именах? Извините за очевидное.
Крис
1
@ Крис: Вы никогда не можете доверять программисту, чтобы понять очевидное! (Хотя в этом случае у меня есть.)
Джон Пурди
7
Если есть причина любить $varсинтаксис PHP , то это оно.
Джои Адамс
3
@ Джои Адамс: я коротко улыбнулся, когда увидел этот вопрос, и вспомнил все вопросы о бешеной PHP, распространяющиеся вокруг SE.
Крис
3
Очевидно, измените исходный код языка, чтобы разрешить мои соглашения об именах. Это также имеет преимущество «защиты» моего кода, поскольку он будет запускаться / компилироваться только на моем интерпретаторе / компиляторе.
dietbuddha

Ответы:

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

  2. Считайте более конкретным. Ключевые слова , как правило, достаточно широк, так что сужение classвплоть до demonstrationClassне работает только вокруг вопросов , но и повышает читаемость.

Maxpm
источник
10

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

  1. Попробуйте найти синоним.
  2. (особенно для переменных) попробуйте найти префикс или постфикс
  3. (особенно для классов) измените первую букву на верхний регистр и забудьте о правиле кодирования, согласно которому имена не должны отличаться только регистром. Эту опцию я бы, вероятно, использовал, только если конфликт связан с ключевым словом.
  4. Используйте аббревиатуру.
Барт ван Инген Шенау
источник
1
Я не вижу, что не так с именами, отличающимися только регистром, особенно в списках аргументов, где параметр типа const Foo&не имеет никакого разумного полного имени, кроме foo. Конечно, было бы лучше дать вашему Fooболее описательное имя, чем fooесли бы оно находилось в теле функции и служило менее специализированной цели.
Джон Пурди
@Jon - согласен, хотя лично я склоняюсь к префиксам «p_», «l_» и «m_», а не к регистру. Я принял эту конвенцию из-за проблемы «все имеют одно и то же очевидное имя». Какое соглашение вы используете, чтобы справиться с этим, в значительной степени не имеет значения, если вы используете его последовательно в любом конкретном контексте, конечно - подход с учетом конкретных случаев, безусловно, используется достаточно широко, чтобы большинство разработчиков могли его распознать.
Steve314
@Jon - этот комментарий звучит так, будто я выборочно применяю соглашение только тогда, когда у меня проблема с одинаковыми именами, что я не имел в виду. Проблема контекста относится к языку, проекту и т. Д. Соглашения составлены таким образом, что проблема не является проблемой, когда она возникает (или, скорее, не возникает), а не применяется избирательно при необходимости.
Steve314
@ Steve314: Я понял ваш смысл из первого комментария. Я не знаю, такие аффиксы всегда были слишком близки к венгерским системам для моего комфорта.
Джон Пурди
@Jon: это не правило, которое я применяю неукоснительно, но я считаю, что легче делать ошибки, если два идентификатора отличаются только регистром. Некоторые из этих ошибок будут обнаружены компилятором, некоторые гораздо сложнее найти (особенно, если два идентификатора называют одно и то же). Я предпочитаю иметь одно общее правило, с исключениями в каждом конкретном случае, чем полное собрание правил, охватывающее все возможные случаи.
Барт ван Инген Шенау
6

Язык побеждает; Вы не можете перехитрить компилятор (игнорируя такие мерзости, как PL / 1 IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF END, но тогда PL / 1 не заставит вас задавать вопрос в первую очередь). По сути, вы должны следовать правилам языка, и вы должны найти альтернативу ключевым словам языка для вашего собственного использования - или найти альтернативный язык.

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

Джонатан Леффлер
источник
5

Вместо сокращения, как насчет удлинения? Если вы реализуете конструкцию класса на языке Foo, как насчет использования FooClass и foo_class? (По модулю, какими бы ни были ваши предпочтения в отношении корпуса).

Уинстон Эверт
источник
Вы бы добавили префикс «java» к каждому идентификатору, который вы используете в коде Java? И давайте даже не
будем
@ Steve314, вы бы не использовали префикс java в коде java, вы бы использовали префикс java в коде c ++, который реализует компилятор java. Кроме того, вы бы использовали его, только если остальная часть идентификатора была ключевым словом.
Уинстон Эверт
ОК - вы имеете в виду удлинение в общих чертах, как, например, уточнение идентификатора. Для разных приложений «класс» может быть переименован в «class_taught» или «class_of_animal» или «classiness_value» или что угодно. Я согласен - я просто нашел пример, ориентированный на компиляторы, сбивающий с толку.
Steve314
5

Некоторые из сокращений, которые я использовал class, в порядке частоты:

  • cls
  • clss
  • clazz
  • theClass
  • aClass

Если я знаю, какой класс Classпредставляет экземпляр, я мог бы включить его в имя переменной:

  • stringClass = Class.forName("java.lang.String");
Майк Кларк
источник
Никогда не видел "cls" для этого раньше. Я в основном использую aClass.
Константин Петрухнов
4

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

В Модуле 2, ключевые слова прописных буквы - но до тех пор , пока ваши идентификаторы имеют некоторые строчные буквы разница очевидна и столкновение невозможно.

Кроме того, соглашения об абсолютном именовании в некоторой степени должны отражать обычные соглашения языка, который вы используете, поэтому я, безусловно, напишу «myClass» на Java, где я, скорее всего, напишу «My_Class» на C ++.

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

Steve314
источник
3
Даже для чувствительных к регистру языков, я чувствую, что смешивание classи Classповредит читабельности кода.
Кармастан
@ Кармастан - возможно, это зависит от того, сколько времени вы потратили на работу с чувствительными к регистру языками и соглашениями. Лично верхний и нижний регистр «C» визуально очень очевидны - я вижу шаблоны использования регистра для длинных идентификаторов быстрее, чем я могу их прочитать.
Steve314
3

Я не часто сталкиваюсь с этим, но когда я делаю это, это, как правило, не проблема, потому что я использую Delphi, и это позволяет вам обойти эту проблему, добавляя & к идентификатору. Таким образом, «класс» не является допустимым идентификатором, но «& класс» является.

Мейсон Уилер
источник
Интересный. У меня есть утилита генерации кода, которая позволяет строковые литералы везде, где можно использовать идентификатор. Первоначально большинство идентификаторов для сгенерированного кода были написаны как строковые литералы, чтобы избежать риска столкновения ключевых слов с растущим (и богатым ключевыми словами) DSL. Теперь идентификаторы используются для большинства имен (удивительно, насколько более читабелен этот источник), но строковые литералы всегда доступны в качестве запасного варианта. Я думал, что это хорошо для генерации кода, но обходные пути с ключевыми словами будут плохой идеей для языка общего назначения - но, возможно, я ошибаюсь.
Steve314
2

Я бы добавил какое-то пространство имен к имени переменной. Например, предположим, что у вас есть модуль с именем user, тогда я бы изменил оператор имени переменной на что-то вроде user_operator или userOperator.

Pemdas
источник
2
только не используйте «smooth», «no» или «my» в качестве префикса
Стивен А. Лоу
2
Абсолютно. Я голосую "Jon_Purdys_Carefully_Chosen_Identifier_Prefix_".
Steve314
1
@ Steven: еще хуже, я вижу a, anи theиспользуется с тревожной частотой начинающими студентами CS.
Джон Пурди
1
@ Джон Парди, это не наша вина! Виноват профессор, который решил назвать свой экземпляр класса People () aPerson.
Бен Л
@Jon: Соглашение об именах, в котором я работаю, определяет, что локальные переменные должны начинаться, aкроме переменных с жестким циклом: /
Matthieu M.
2

изменить или настроить мое соглашение об именах

Муад'Диб
источник