вопрос практикующим программистам

[mbla]

У наших студентов на пятом курсе полугодовая стажировка.

Найти стаж обычно просто - всем хочется получить готового инженера по дешёвой цене - платят стажёрам, естественно, мало.

Обычно ребят берут разработчиками на конкретные проекты.

После окончания стажировки - защита - в комиссии кто-то от нас и руководитель стажа "с места". Иногда руководитель с места по тем или иным причинам отсутствует и вместо себя присылает оценочную бумагу.

Сегодня у меня "защищал" свою работу мальчик, у которого страсть - интеллектуальные компьютерные игры. Ему удалось найти соответствующий стаж. В компании, которую 5 лет назад организовали двое братьев - совсем молодые ребята - были у них какие-то идеи, взяли кредиты. Сейчас в компании шестеро, естественно, друзья-сокурсники. Такие маленькие фирмы, по крайней мере во Франции, всегда дружеские тусовки.

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

Первое - понятное - функция должна умещаться на экране - не умещается - разбивай.

А вот второе меня поразило - комментарии запрещены. Идея в том, что комментарии позволяют писать нечётко, - дескать, прочтёт человек комментарий и всё поймёт, а на самом деле, ежели код хорошо написан, он должен быть полностью понятен при чтении с листа.

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

Как по-вашему?

Comments

[lena-shagina.livejournal.com]

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

[yucca.livejournal.com]

Я так и пишу - почти без комментариев. Но при этом ужасно мучаюсь совестью.

[alex-legat.livejournal.com]

американские компании - заказчики софта - всегда требуют комментирования. это стандарт. чтобы другой программист смог при необходимости разобраться.

[alta-voce.livejournal.com]

Я думаю, они плохо по-французски умеют писать. ;-)
Сто лет назад комментарии поощрялись.

[cema.livejournal.com]

Комментарии нужны, но оценку за них снижать глупо. Я пытался биться за это, но увы.

[pendelschwanz.livejournal.com]

Так и надо.
Технология программирования которой учили в школе на заре прошлого века, строится на следующих неверных мифах:
1. Сама технолгия достаточно хороша и набрав сотню программистов с улицы из перевоспитавшихся допризывников, можно сделать большой проект.
2. Работу программиста можно измерить, и написанные спецификации увеличивают ее удельную эффективность
3. Самый большой грех - повторное написание уже написанного
4. Длиный текст не должен содержать goto потому что будет спагетти
.....................
Я знаю на самом деле только две абсолютные истины, которые очень близки к вышеперечисленной хакерской мудрости
1. Любая программа должна быть обозрима. Все что мешает обозримости (переструктурность, длинноты, комментарии) - вред
2. Программу не должен писать м$дак

[liber-polly.livejournal.com]

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

businesses' dilemma

[ivan-ghandhi.livejournal.com]

Гениально!

[ivan-ghandhi.livejournal.com]

javadoc only. The rest is shit.

[starushka-su.livejournal.com]

Хоть и не практикующий, а бывший. Самому писать комменты всегда, конечно, лениво, но читать без них ужасно хуже :)
А по поводу краткости вполне согласна

[kot-ivanovich.livejournal.com]

Хм... Я — менеджер в американской компании, которая заказывает кучу софта в России, Украине, Индии, Китае, Канаде. В гробу мы видали комментарии...

[http://users.livejournal.com/roxana_/]

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

[kot-ivanovich.livejournal.com]

Абсолютно согласен с "отцами-основателями". С функциями, не влезающими на экран, я борюсь нещадно (хотя не всегда успешно).

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

if ((x > 0) && !(x&(x-1)) {

понятно многим, но не каждому. Плохо. Переписываем:

inline bool is_power_of_2(int x)
{
return (x > 0) && ((x&(x-1)) == 0);
}
.....
if (is_power_of_2(x)) {

Теперь вроде и ежу понятно...

Исключения — отсылки к литературе или внешней документации.

Но это я именно про комментарии к коду. Комментарии к данным писать чаще надо, чем не надо...

[kot-ivanovich.livejournal.com]

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

[andrzejn]

Совершенно правильная практика. Мы тоже её придерживаемся. Разумеется, не в формулировке "комментарии запрещены", а именно "тело метода должно быть понятно без комментариев". Для общего описания сути есть спецификации, план разбивки задания на подзадачи, комментарии в заголовке класса.

Ещё несколько правил, нагло содранных мною из идеологии Eiffel:

1. Метод должен либо изменять состояние объектов (процедура), либо возвращать значение (функция). У функций побочных эффектов быть не должно. Помогает избегать глюков типа "вставили функцию в проверку условия и забыли о побочных эффектах" и искать вредные побочные эффекты (в функции можно не заглядывать).

2. Перехватчик исключений (блок try...catch/finally) должен быть один на метод, чаще всего - охватывать всё тело метода. Если нужно больше - надо дробить метод на несколько. Это требование того же рода, что и "функция должна помещаться на экране". Метод должен делать только одно логическое действие, а не сначала одно, потом другое.

3. Избегать private переменных и методов (видимых только методам этого класса). Вместо них использовать protected (видимые классу и наследникам). Лучше допустить, что кто-то завяжется на внутреннее устройство класса непредусмотренным образом, чем изобретать кривые обходные пути вокруг произвольно закрытой функциональности.

[clement.livejournal.com]

А если не Java?

[clement.livejournal.com]

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

[andrzejn]

Мне больше нравится идея, что эти условия и инварианты лучше оформлять в виде assert'ов, чтобы не только программисты их читали, но и при исполнении их нарушение контролировалось. В комментарии выносить разве что те условия, которые проверяются недопустимо долго.

[andrzejn]

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

[clement.livejournal.com]

Если язык поддерживает эти assert, то да, конечно.

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

[andrzejn]

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

[clement.livejournal.com]

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

Кто бы с этим спорил ;-)

[andrzejn]

Заказчики и высшее руководство ;)

[clement.livejournal.com]

;-)

[a_p]

Такая практика может быть полезна для обучения программированию, как и вообще следование каким-то допускающим обоснование правилам (типа функция не больше 30 строк). С опытом (или просто с возрастом? :)) фанатизм в следовании правилам проходит. То есть комментарии используются там, где надо, а функции, хоть и редко, вылезают за экран.

Вообще, следование общим правилам восполняют недостаток конкретного умения-понимания. Поэтому оно полезно в неоднородных по уровню коллективах.