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

[mbla]

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

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

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

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

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

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

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

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

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

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

Comments

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.

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

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