Мысли о соглашениях об именах переменных / функций

Я программировал то и дело всю свою жизнь. Я в основном писал Perl, но также немного писал на Java, PHP, C, C ++. Я даже попробовал Emacs Lisp и время от времени делал сценарии оболочки. Однако на самом деле я никогда не привлекал эту тему для получения каких-либо знаний - другие вещи были для меня более важными. Я не считаю себя хорошо владеющим каким-либо языком, кроме Perl, а теперь еще и Haskell, курс по которому я сейчас изучаю.

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

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

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

-- return the row with least number of Nothing values
bestRow :: [[Maybe Int]] -> Int -> Maybe (Int,Int)
bestRow [] _ = Nothing
bestRow (row:rows) thisIndex
   | nextRow == Nothing && thisFilled > 8 = Nothing
   | nextRow == Nothing       = Just (thisIndex,thisFilled)
   | thisFilled >= nextFilled = Just (thisIndex,thisFilled)
   | thisFilled <  nextFilled = nextRow
     where thisFilled             = length $ filter (/= Nothing) row
           nextRow                = bestRow rows (thisIndex + 1)
           (nextIndex,nextFilled) = fromMaybe (-1,-1) nextRow

Я не мог определиться с именами переменных. Функция выполнила свою задачу хорошо, но это было не так ясно, как могло бы быть. Выбрав решение, я потратил 15 минут на присвоение имен и переименование переменных. Следует ли мне использовать curIndex, nextIndex || index, nextIndex || ind, indN и т. д.? Через 15 минут после того, как я решил, что все готово, я понял, что эта функция в конце концов не нужна: я нашел гораздо лучшее решение своей проблемы. БУМ Я потерял много времени, просто чистя код, который никому не нужен, и тем более мне. По крайней мере, так казалось.

Это то, что случалось со мной не раз, и это меня очень расстраивает, в основном потому, что заставляет меня чувствовать себя немым. Что вы думаете по этому поводу? Это что-то, что вы испытали, что-то не так с моим поведением или просто что-то неизбежное?

Существуют ли «идеальные» имена переменных, или это «нормально», если они хотя бы не запутывают ваш код?

Спасибо,

Стефан Кангас


coding-style
person Stefan Kangas    schedule 01.10.2009    source источник
comment
Вероятно, вы теряете меньше времени, очищая плохой код, а затем выбрасывая его, чем не очищая и не оставляя его. Я хочу, чтобы люди, с которыми я работаю, беспокоились об именах переменных так же сильно, как и вы.   -  person Terry Wilcox    schedule 02.10.2009

Ответы (3)


arrow_upward
5
arrow_downward

Прочтите книгу Роберта К. Мартина «Чистый код».

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

Цель - создать код, который читается как рассказ. Изменение имен переменных и функций и разбиение их на несколько функций или переменных, если необходимо для достижения этой цели.

Отличная книга, стоит каждой копейки

person CaffGeek    schedule 01.10.2009
comment
+1 - имена переменных и функций должны быть комментариями сами по себе. Тем не менее, есть некоторые бессмысленные, но устоявшиеся практики именования (например, _1 _, _ 2 _, _ 3_ для контура управления), которым лучше всего следовать просто потому, что все в этой области ожидают, что вещи уже будут называться таким образом. - person Pavel Minaev; 01.10.2009
comment
В общем, опять же из книги, чем короче область видимости переменной, тем короче может быть ее имя. Следовательно, управляющие переменные в цикле могут состоять из 1 символа ... и это хорошо устоявшаяся практика, это то, что ожидается. - person CaffGeek; 01.10.2009

arrow_upward
0
arrow_downward

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

Ясность кода - это хорошо.

person Gregor Brandt    schedule 01.10.2009

arrow_upward
0
arrow_downward

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

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

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

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

person Dal    schedule 01.10.2009
comment
Но если у ваших переменных заранее есть описательные имена, в этих комментариях нет необходимости. Например. Если вы видите переменную с именем email, что это такое? Это адрес электронной почты человека? Или это логическое значение, указывающее, хотят ли они получать электронную почту? Или логическое значение, указывающее, есть ли у них адрес электронной почты. Если бы он был назван hasEmail или emailAddress, мы были бы более уверены. Даже если у вас был комментарий, я действительно не хочу прокручивать до определения, чтобы найти ответ. - person CaffGeek; 01.10.2009