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

[mbla]

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

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

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

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

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

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

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

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

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

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

Comments

[afrolover.livejournal.com]

Да кому они вообще нужны, эти комментарии? Особенно, когда вы пишете функцию типа "возведение в степеь целого числа".

А в реальной жизни иногда подолгу думаешь, как оптимизировать тот или иной кусок кода. Так вот, тот, кто будет читать этот код (без комментариев) проведёт ещё больше времени, чтобы его понять...
Я уж не говорю, что есть вещи, которые просто нечитабельны. В C++ шаблоны (templates) нечитабельны. Будьте вы плохим программистом или хорошим. Это не от вас зависит - это проблема языка. Поэтому комменты, пусть самые кратенькие, очень скрашивают жизнь...
Ща попробую выковырять откуда-ниб примерчик

// [if O1_size available, then attempt which_t size optimization...]
// [select signed char if fewer than SCHAR_MAX types, else signed int:]
typedef typename mpl::apply_if<
mpl::equal_to< mpl::O1_size, mpl::long_<-1> >
, mpl::identity< int >
, mpl::if_<
mpl::less< mpl::O1_size, mpl::int_ >
, signed char
, int
>
>::type which_t;

на мой взгляд, комментарии тут совсем не лишние...

[greenadine.livejournal.com]

Или взять perl. Кусочек кода без комментариев...

[afrolover.livejournal.com]

ага, какой-нибудь маленький регэкспик...
((?:(?![-_])[\w-]+\.)+[A-Za-z][\w-]+)
ну какому дураку тут понадобятся комментарии? Читайте код, господа...

[kot-ivanovich.livejournal.com]

Черт его знает... Я не программирую на Perl и за комментарий к этому "регэкспику" был бы, естественно, благодарен. Но: наш configuration management engineer, который только на Perl и пишет, скорее всего, счел бы такой комментарий помехой. Если цель — написать так, чтобы было понятно не профессионалу, то, конечно, комментарии нужны. Только нет ее, этой цели, обычно.

[afrolover.livejournal.com]

отличие профессионала от чайника - в скорости "раскрутки" такого выражения. Но в любом случае, оно будет не очень быстрое. И дело тут не в профессионализме, а в недостатках языка. Так почему же не написать маленький комментарий о том, что эта строчка кода делает? Тогда, вместо головоболезненного вникания в букву за буквой, любой "прочтёт" эту строчку сходу...
И почему нужно писать для профессионалов? А если мой код будут читать не только "крутые программеры"? Что, если новичок захочет взять его за пример и разобраться? Если бы Ландау и Фейнман писали только для таких крутых мужиков как они, нам бы было гораздо труднее учиться физике...

[mbla.livejournal.com]

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

[afrolover.livejournal.com]

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

Да чего тут спорить - возьмите какую-нибудь широкоупотребимую и общепризнанную библиотеку для вашего любимого языка и посмотрите её исходники... Это будет хорошим примером профессионального программирования ;-)

[mbla.livejournal.com]

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

[afrolover.livejournal.com]

да, конечно, код должен быть наиболее читаемым, переменные должны говорить сами за себя и т.д. Но, как показывает практика, даже при выполнении всех этих правил, иногда сидишь и смотришь на чужой код (а иногда и на свой собственный, но забытый) как баран на новые ворота. Т.к. даже в языках высокого уровня, где всё читается "само собой", программисту порой приходится принимать те или иные алгоритмические решения. Например, нужно отсортировать массив. Сразу пишу маленький комментарий: "Сортирую XXX методом, т.к. в большинстве случаев матрица пустотелая" (или как это по-русски?). Заметьте, это может быть и неправдой (я ошибся в предположении, или неправильно выбрал метод сортировки для пустотелых матриц), но тому кто читает, сразу ясно, что творилось у меня в голове и почему я сортировал так или иначе. И он сразу сможет судить о правильности моего кода. Если же я напишу без коментария, то народ будет сидеть и ломать голову. При этом половина не додумается до моей умной идеи и будут думать "вот козёл! выпендрился на ровном месте!", а другая половина придумает решение по-гениальнее и тоже будут недоумевать, почему я так сделал. Но и те и другие будут бояться править мой код, т.к. не будут до конца уверены, какая же мысль у меня бродила в голове, побудившая меня написать именно так. И, в конце концов, мой код так и останется неисправленным, т.к. чтобы его исправить, человек должен быть на 100% уверен в своей правоте, а всегда остаётся небольшое "вдруг он всё-таки умнее и видел что-то, чего не заметил я?".

Код должен читаться, а не быть головоломкой. И "головоломность" может происходить не только из корявого написания, но и из оптимизаций и идей пишущего. И, даже если я пишу мой код только для "крутых профессионалов", почему не объяснить им человеческим языком, что меня побудило сделать тот или иной выбор и что у меня было в голове в тот момент? Это им позволит сходу вникнуть в мой код и судить о гениальности или ущербности моей идеи, не ломая голову и не теряясь в догадках.

[mbla.livejournal.com]

Понимаю. Но ведь алгоритмический язык на то и алгоритмический, чтоб на нём можно было читать по-человечески. Может быть, алгоритм с комментариями внутри в качестве комментария? Не комментировать код, что часто делает его ещё менее читаемым, а приложить к коду алгоритм с объяснениями, почему был сделан определённый выбор?

[andrzejn]

О! Да. Я совсем забыл про оптимизации, когда код становится быстрым, но нечитаемым...
Да, там комментарии чрезвычайно полезны.
Правда, мы практикуем подход "сначала сделать красиво и наглядно, а потом искать и оптимизировать узкие места". В этом случае комментарием к оптимизированному кошмару становится просто закомментированный предыдущий читабельный фрагмент кода, который делал то же самое, но неоптимально, и примечание о факте проведения оптимизации.

[mbla.livejournal.com]

Естественно!

[afrolover.livejournal.com]

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

[mbla.livejournal.com]

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

[andrzejn]

C - отличный язык в своей нише, но это ниша портабельных ассемблеров, где-то по соседству с Forth. "Язык C сочетает гибкость и эффективность ассемблера с наглядностью и простотой ассемблера" :)

C++ - кошмар, распространившийся лишь благодаря внешнему сходству с C. Впрочем, об этом кто только не говорил... Мне понравился документ "A Critique of C++ (3rd Edition)".

[mbla.livejournal.com]

Для меня это больная тема - практически всюду выкинули из программ обучение алгоритмике на паскале, потому как паскаль не употребляется в реальной жизни, и учат на С. А С плохой алгоритмический язык!

[andrzejn]

Да, алгоритмический язык для обучения из него плохой. Вдобавок, устаревший как язык общего назначения.
И почему бы не вести обучение на чём-нибудь более современном - не Object Pascal, так хоть VB.NET?

[mbla.livejournal.com]

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

[afrolover.livejournal.com]

очень сложно создать язык, который бы был с одной стороны очень мощным, с другой стороны читабельным/писабельным. Ассемблер - очень мощный язык. Всё можно сделать. Но на нём не пишут даже профессиональные программисты, потому что на нём писать невозможно... А те, кто вынужден на нём оптимизировать свой код, пишут очень много комментариев, так как никто, даже самый "про" не способен отследить перекидывание битов из регистра в регистр и восстановить глобальную идею по сотням строчек нечитабельного кода...
Есть языки высокого уровня, в которых потребность к коментариям гораздо меньше. Чем ближе язык программирования к человеческому языку, тем легче его понять и тем меньше нужно комментариев. Но, к сожалению, пока ещё не научились делать такие языки достаточно мощными и "безопасными".
Поэтому приходится выбирать промежуточные решения. И чем ниже вы опускаетесь, тем сложнее становится читать и писать код.

[greenadine.livejournal.com]

Лена, а не видела ли ты другой интуитивно понятный без комментариев язык (http://en.wikipedia.org/wiki/Brainfuck)? Тоже с говорящим названием :-)