Почему читабельность кода имеет значение?

[ArtyomTrityak]

… или прочитайте книгу Макконнелла «Совершенный код»

[yuk]

главу 31(layout and style) и 32(self documenting code).

[Colwin]

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

[Joka]

а потом Фаулера «Рефакторинг»

[paranoik]

Я бы посоветовал Питер Гудлиф «Ремесло программиста. Практика написания хорошего кода»

[mrShadow]

На эту статью бесполезно убивается меньше времени, так что лучше уж её, спасибо.

[burivuh]

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

[mrShadow]

Я тоже прочитал, кроме глав об именовании переменных и пр., содержимое которых, я считаю, людям хоть с каким-то опытом программирования не хелло-вордов должны быть очевидны. Но почему-то в голове почти ничего не отложилось, кроме рассуждений типа того, насколько ошибки, обнаруженные на этапе проектирования, «дешевле» тех, которые обнаружены на более поздних этапах, и пр. Возможно, мой опыт работы (три года) слишком мал (либо работаю я над кодом «не того уровня»), чтобы то, о чём говорит Макконнелл, до меня дошло. Те довольно общие вещи, которые излагаются в книге, плохо усваиваются, если не приложены к практике (и, соответственно, если практики нет ни в книге, ни в реальной жизни, не усваиваются вообще). Поэтому мне кажется, что я только потратил на неё время.

tl;dr Моё мнение, что до осознания полезности этой книги наверное надо профессионально дорасти. Иначе трата времени.

P.S. Книгу читал года полтора-два назад, так что мог и подзабыть вообще, о чём она :)

[Colwin]

1. Слова, написанные в книге, забываются, это факт.
2. Но во время чтения невольно сравниваешь свой стиль с предложенным, обнаруживаешь лучшие приемы, чем те, которые использовал, меняешь свое мнение по некоторым вопросам.
3. После этого ты можешь не помнить всего того, что написано в книге, главное — что она изменила тебя и твое мышление, и твой код стал лучше. Даже если ты не отдаешь себе в этом отчета.

[Colwin]

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

[Colwin]

Вы понимаете разницу между хорошим и плохим кодером, не говоря уже о разработчиках?
Судя по всему, нет.

[spmbt]

Или пора вводить должность «Косметолог программного кода».

[ara89]

Некоторые из описанных пунктов можно выполнить просто нажав комбинацию клавиш в IDE.

[GraD_Kh]

Практически все из перечисленных пунктов должны входить в кодинг-стандарты, и собственно все.

[xappymah]

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

[paranoik]

Разбиение методов на более компактные — extract method.

Именование переменных считаю давно можно было бы реализовать. Настраивать в IDE casing + префикс для private fields и вперед…

[Regis]

JetBrains IDEA распознает в коде места где форма написания имен методов, переменных и прочих не соответствует Code Style проекта. Что касается префиксов приватных имен — как минимум для Python'а IDEA корректно интерпретирует "_" как маркер приватности (не знаю, как эта IDE дружит с другими языками помимо Java и Python).

[aleXoid]

Почему иногда не стоит писать длинные статьи, когда первое же предложение избыточно?

[orionll]

Да ладно, вредного же ничего в статье нет.

[Veterinar]

Она состарила меня на 15 минут.

[Colwin]

Если Вы доросли до того уровня, когда данная статья кажется очевидностью, имеет смысл понимать, что не все еще достигли этого уровня.
Иными словами, Вы умны, уважаемый, но мудрости Вам еще стоит поучиться ©.

[Neofant]

Спасибо за статью и за книжки в комментах. Полезный совет никогда не бывает лишним.

[averkin]

Читабельность кода имеет значение, потому что существует вероятность, что его будет читать «склонный к насилию психопат, который, к тому же, знает, где Вы живёте».
(с), Если Перефразировать С. Макконнелла.

[herfleisch]

С десятым пунктом не согласен. Комментарии устаревают раньше, чем их кто-то прочтет. Их бояться удалять, потому что они могут кому-то быть нужными. Но на деле они лишь засоряют код. Я всегда удаляю любые комментарии, заменяя их на понятные имена переменных и функций. Если же кто-то закомментировал код чтобы потом его раскомментировать — для таких вещей существует svn. А засорять код комментариями не надо.

[Nicolette]

А решения типа «это сделано так, потому что заказчики хотели так в письме номер… от ...»? Это даже через месяц вспомнить нереально, а как нужно называть переменные — страшно подумать :-)

[herfleisch]

Мне никто заказчики не говорили такие вещи, как например «В этом месте используйте, пожалуйста, конструкцию switch-case вместо полиморфизма». Такие мелочи — удел программиста, а не заказчика. А для более глобальных вещей существует документация и UML.

[Colwin]

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

[Colwin]

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