Есть ли оправдание коротким именам переменных?

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

Например, я читал какой-то код, который обновляет определение оптической поверхности. Переменные, установленные в начале, были следующими:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

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

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

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

Похоже, что эти имена переменных основаны на аббревиатурах, которые вы ожидаете найти в учебнике физики, работающем с различными проблемами оптики. Это одна из ситуаций, когда короткие имена переменных часто предпочтительнее длинных имен переменных. Если у вас есть физики (или люди, которые привыкли разрабатывать уравнения вручную), которые привыкли использовать общие сокращения, такие как Rin, Rout и т. Д., Код будет намного понятнее с этими сокращениями, чем с более длинными именами переменных. Это также значительно упрощает сравнение формул из статей и учебников с кодом, чтобы убедиться, что код действительно выполняет вычисления правильно.

Любой, кто знаком с оптикой, сразу распознает что-то вроде Rin как внутренний радиус (в статье по физике inони будут отображаться как индекс), Rout как внешний радиус и т. Д. Хотя они почти наверняка смогут что-то мысленно перевести Как innerRadiusи в более знакомой номенклатуре, это сделает код менее понятным для этого человека. Это затруднило бы выявление случаев, когда знакомая формула была закодирована неправильно, и затруднило бы перевод уравнений в коде в и из уравнений, которые они найдут в статье или учебнике.

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

Переменные с коротким временем жизни должны быть названы в ближайшее время. Например, вы не пишете for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Вместо этого вы используете for(int i ....

В целом, можно сказать, что чем короче область видимости переменной, тем короче должно быть имя. Счетчики циклов часто состоят только из одних букв, скажем i, jи k. Локальные переменные - это что-то вроде baseили fromи to. Например, глобальные переменные несколько сложнее EntityTablePointer.

Возможно, подобное правило не соблюдается в кодовой базе, с которой вы работаете. Это хорошая причина для некоторого рефакторинга, хотя!

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

Код просто предполагает знакомство с проблемной областью.

Это нормально, поскольку знакомство с проблемной областью, вероятно, требуется для понимания и поддержания кода, особенно в роли того, кто «владеет» им, поэтому вам следует приобрести знакомство, а не обходить удлинение имен.

Но было бы неплохо, если бы в коде были некоторые подсказки, служащие трамплинами. Даже специалист в области может забыть, что dKэто коническая константа. Добавление небольшого «шпаргалка» в блоке комментариев не повредит.

Для некоторых переменных, которые хорошо известны в проблемной области - как, например, в нашем случае - краткие имена переменных являются разумными. Если я работаю над игрой, я хочу, чтобы мои игровые сущности имели переменные положения, xа yне horizontalPositionи verticalPosition. Аналогичным образом счетчики петли , которые не имеют никакой семантики помимо индексации, я ожидаю увидеть i, j, k.

Согласно «Чистому коду»:

Имена переменных должны:

• Быть разоблачающим намерение
• Избегайте дезинформации
• Сделайте значимые различия
• Быть произносимым
• Быть доступным для поиска

Исключение составляют пресловутые выражения, i,j,k,m,nиспользуемые в циклах for.

Имена переменных, на которые вы, по праву, жалуетесь, ничего не делают из вышеперечисленного. Эти имена плохие имена.

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

Эти имена лучше:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

Комментатор говорит, что это было бы слишком сложно с длинными именами переменных:

Короткие имена переменных тоже не упрощают:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

Ответ - длинные имена и промежуточные результаты, пока вы не получите это в конце:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

Есть две веские причины не переименовывать переменные в устаревшем коде.

(1) если вы не используете автоматизированный инструмент рефакторинга, вероятность появления ошибок высока. Следовательно, «если он не сломан, не чините его»

(2) вы сделаете сравнение текущих версий с предыдущими версиями, чтобы увидеть, что изменилось, невозможно. Это усложнит дальнейшее обслуживание кода.

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

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

dDin better than dDinnerAperture
dDout better than dDouterAperture

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

С другой стороны, если вам сложнее работать, то вырубитесь и переименуйте их в более длинную форму. Особенно, если вы несете ответственность за этот код.

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

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

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

Чтобы создать этот класс «Солнечные часы» , я сослался на полдюжины ресурсов, Астрономический альманах и фрагменты из других языков (PHP, Java, C и т. Д.).

Почти во всех из них они использовали одинаковые идентичные сокращения, которые на первый взгляд ничего не значат.

K, T, EPS, deltaPsi, eot, LM,RA

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

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

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

Там абсолютно есть; часто короткое имя переменной - это все, что необходимо.

В моем случае я занимаюсь навигацией по маршрутам в старших классах по робототехнике, и мы программируем наших роботов на KISS-C. Нам нужны переменные для текущих и конечных (x, y) координат, (x, y) расстояний, текущего и конечного направлений, а также углов поворота.

Особенно в случае координат x и y, длинное имя переменной совершенно не нужно, а имена, такие как xC (текущий x), yD (назначение y) и pD (назначение phi), являются достаточными и их легче понять в этом случае.

Вы можете утверждать, что это не «описательные имена переменных», как диктует протокол программиста, но поскольку имена основаны на простом коде (d = destination, c = current), очень простой комментарий с самого начала - это все описание они требуют.

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

Обычно сложные алгоритмы реализуются в matlab (или аналогичном языке). То, что я видел, это то, что люди просто берут имя переменных. Таким образом, сравнить реализации просто.

Все остальные ответы почти верны. Эти сокращения можно найти в математике и физике, за исключением того, что они не начинаются с d(как в вашем примере). Переменные, начинающиеся с d, обычно называются для обозначения дифференцирования .

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

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

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

Например, как только я привык к тому, что svdb означает «сохранить в базе данных», скорость сканирования исходного кода улучшается, поскольку мне нужно только быстро сканировать 4 символа вместо чтения SaveToDatabase (14 символов, все становится хуже для более сложных имен операций). Я говорю «сканирование», а не «чтение», потому что это занимает большую часть анализа исходного кода.

При сканировании большого количества исходного кода это может обеспечить хороший прирост производительности.

Кроме того, это просто помогает ленивому программисту печатать эти короткие имена при написании кода.

Разумеется, все эти «сокращения», как ожидается, будут перечислены в каком-то стандартном месте в исходном коде.

Чтобы сформулировать то, что сказал @zxcdw, немного по-другому и уточнить это с точки зрения подхода:

Функции должны быть чистыми , краткими и идеально инкапсулировать некоторую функциональность: логика «черного ящика» , независимо от того, был ли он нетронутым в течение 40 лет, будет продолжать выполнять работу, для которой он был разработан, потому что его интерфейс (вход и выход) это звук, даже если вы ничего не знаете о его внутренностях.

Это тот код, который вы хотите написать: это код, который длится и прост в переносе.

Где необходимо, составьте функции из других (встроенных) вызовов функций , чтобы сохранить детальный код.

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

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

Нет веской причины не использовать описательное имя. Это поможет вам и всем, кто работает / будет работать над проектом. Ну, на самом деле есть единственное допустимое использование для коротких имен: счетчики циклов.

Конечно, это то, что // комментарии для?

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

Для интерфейсов (например, сигнатур методов, сигнатур функций) я стараюсь решить эту проблему путем аннотирования объявлений параметров. Для C / C ++ это украшает файл .h, а также код реализации.

Я делаю то же самое для объявлений переменных, где знание использования переменной не очевидно в контексте и в именовании. (Это относится к языкам, которые также не имеют строгой типизации.)

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

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

Есть ли оправдание за слишком короткие имена переменных?

Во-первых: присвоение имени энергии e при вычислении формул, таких как E = MC2, НЕ является слишком коротким присвоением имени. Использование символов в качестве аргумента для коротких имен недопустимо

Этот вопрос был довольно интересным для меня, и я могу думать только об одном оправдании, и это деньги.

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

(Просто чтобы сохранить пример «реалистичным», вам не разрешили использовать инструмент минификатора, почему? Проблемы с безопасностью, никакие внешние инструменты не могли коснуться основы кода.)

Я заметил, что в других ответах не упоминается использование венгерской нотации. Это ортогонально длине дискуссии, но в целом относится к схемам именования.

double dR, dCV, dK, dDin, dDout, dRin, dRout

Буква «d» в начале всех этих переменных означает, что они двойные; но язык навязывает это в любом случае. Несмотря на краткость этих имен, они до 50% избыточны !

Если мы собираемся использовать соглашение об именах для уменьшения количества ошибок, нам гораздо лучше кодировать информацию, которая не проверяется языком. Например, ни один язык не будет жаловаться dK + dRна приведенный выше код, даже если бессмысленно добавлять безразмерное число к длине.

Хороший способ предотвратить такие ошибки - использовать более сильные типы; однако, если мы собираемся использовать double, то более подходящей схемой именования может быть:

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

Язык все еще позволяет нам писать K + lR, но теперь имена подсказывают нам, что это может быть неправильно.

В этом разница между системами венгерского (обычно плохо) и приложений венгерского (возможно, хорошо)

http://en.wikipedia.org/wiki/Hungarian_notation

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