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

Question

Я кодировал и выключал всю свою жизнь. Я в основном кодировал 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 || инд, индн и т. д.? Через 15 минут после того, как я решил, что все готово, я понял, что эта функция не нужна, в конце концов: я нашел гораздо лучшее решение своей проблемы. БУМ Я потерял много времени, просто чистя код, который никому не нужен, и меньше всего - мне. Или, по крайней мере, так оно и было.

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

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

Спасибо

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Ясность хороша в коде.