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

[mbla]

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

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

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

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

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

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

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

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

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

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

Comments

[andrzejn]

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

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

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

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

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

[mbla.livejournal.com]

Понятно. Про побочные эффекты - это борьба с программистами на С, которые обожают строить решения на побочных эффектах.

[andrzejn]

Да и не только на C. Все mainstream языки (C/C++, Object Pascal, Java, VB[.NET], C#) слишком легко позволяют обвешивать методы побочными эффектами.

[kot-ivanovich.livejournal.com]

Хм. Классический пример: bool from_string(T * dst, const char * src); Что в нем плохого?

[andrzejn]

Возвращает true, если успешно преобразует src в dst, иначе возвращает false? В идеологии языка C - всё хорошо, так и должно быть. Но это ведь C++?

Противоречит правилу: "Если метод завершается неудачно, он должен не возвращать признак неудачи, а бросать exception". Это правило (как и весь механизм исключений) было введено, чтобы отделить основную логику метода от проверок на ошибочные ситуации. А это нужно, чтобы, читая текст метода, легче было понять его предназначение. Без комментариев :)

[kot-ivanovich.livejournal.com]

Point taken :-))

Never say never

[kot-ivanovich.livejournal.com]

Маленькая проблема как этого обсуждения, так и вообще любой попытки написать Coding Standard, состоит в том, что обсуждаются слишком тривиальные примеры...

Не успел я согласиться с Вашим ответом, как набрел на забавный пример: я вчера правил некий самопальный компилятор (не мной писанный), в котором весь разбор входного текста делает класс Parser: public BasicParser, а у BasicParser по сути два метода: bool Test(const char * token) и void Check(const char * token), так что разбор, скажем, опций, которые можно задать в квадратных скобках, пишется:

   if (Test("[")) 
   {
      do {
         if      (Test(Option1)) ....
         else if (Test(Option2)) ....
         else if (Test(Option3)) ....
      } while (Test(","));

      Check("]");
   }

Я даже не полез читать базовый класс — и так ясно, что эти функции делают... А ведь Test, которая с виду невинно возвращает bool, меняет состояние класса, да еще как! Это нарушение дискутируемого принципа почище невинного изменения параметра, переданного по ссылке, а тем не менее весь дизайн вполне прозрачен и удобен.

Re: Never say never

[andrzejn]

Я согласен с тем, что любой хороший Coding Standard должен содержать пункт: "В некоторых ситуациях этот стандарт лучше нарушать, чем соблюдать".

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

Да, действительно, по этому куску кода всё сразу понятно. Хотя за такие "наглядные" имена методов автору нужно что-нибудь оторвать :)

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