Так получилось, что в течении небольшого времени от нас ушли сразу несколько толковых разработчиков (и один бестолковый, но это не важно :) ). Соответственно помимо основной работы я остался на поддержке зоопарка ПО, реализованного в разных средах:
— assembler (ARM, ADSP-21xx)
— embedded C (IAR for ARM)
— обычный C (gcc for Win)
— C++ (gcc и MSVS for Win)
— C#
— python (скрипты для сборки, кодогенерация)
Мне всегда нравилось приводить в порядок чужой код, исправлять чужие баги. Не как основная работа, а как некоторая разминка для ума плюс хороший способ научиться другому подходу, нежели чем привычный, к разработке (в последних крупных проектах помимо руководства и программирования я взял на себя и задачу исправления ошибок — получилось эффективнее, чем у непосредственных разработчиков). Но так как теперь это большая часть основной работы, некоторые моменты начали раздражать.
Основная проблема в том, что как оказалось многие забыли или просто не задумывались об одном из основных принципов разработки — KISS (Keep It Simple Stupid).
Как это проявляется:
1. Выражения и приоритеты операций. Многих еще в ВУЗе плотно гоняли на курсе программирования по приоритетам операций. Часто до такой степени, что даже если разбудят посреди ночи — сходу расскажешь все приоритеты операций языка Си. В итоге код, который генерируют такие деятели является готовыми задачами для курса программирования. Но реальный код пишется не для экзамена!
Когда в выражении три-четыре операций при беглом просмотре разобраться не сложно, но когда их уже пять-шесть — начинаешь притормаживать, семь и больше — начинает отвлекать от более глобальных вещей. Расставьте скобки — никто вас за это уважать не перестанет, а тот кому придется потом во всем разбираться (возможно это будете вы сами через несколько лет) только спасибо скажет.
Длина выражения должна быть такой, чтобы сразу было понятно, что происходит. Как вам такой код:
Я обычно на таком подвисаю на несколько минут и, по опыту, обычно в таких выражениях и нахожу ошибки. Разбить выражение на несколько несложно, нормальный компилятор потом все равно оптимизирует, а разбираться будет куда легче, да и вероятность ошибки упадет в разы.
2. Комментарии. Не буду капитаном очевидностью разглагольствуя на тему «в коде должны быть комментарии». Дело тут в другом:
— когда пишите комментарии хоть чуть-чуть думайте, как их будут понимать другие люди или вы сами через пару лет
— бессмысленные комментарии только отвлекают от чтения кода
— если поправили код — поправьте комментарии (вот за такую лень пару раз хотелось просто убить, а один раз разработчик при мне сам на этом попался) так, чтобы было соответствие коду
Я уже давно сначала пишу комментарии (по сути псевдокод-описание алгоритма), а потом уже кодирую. Реально помогает. И кодируется быстрее, и ошибок меньше, и поддерживать такой код потом проще. А если сразу писать комментарии так, чтобы потом можно было все скормить doxygen'у (или подобному средству), то вам потом не раз спасибо скажут…
3. Форматирование. Каждый привык к определенному виду форматирования исходных текстов. Количество сломанных копий в спорах на тему лучшего способа оформления Си-кода уже наверное не поддается подсчету. Я спокойно отношусь к тому, что способ форматирования в коде, в котором разбираюсь отличен от удобного мне, но наплевательское отношение к форматированию раздражает очень сильно. Я конечно могу запустить justifier, но почему бы самому разработчику это не сделать, если лениво сразу код красиво писать?
4. «Я мастер <Си, python, C++ и т.д.> и мой код должны читать опытные люди». Может за это мне и наставят минусов, но иногда стоит думать о том, что ваш код может поддерживать человек, который не так хорошо владеет (а может вообще не владеет) доступными вам технологиями и написать его максимально упрощая.
К примеру, если вы пишете скрипт сборки релиза Си/С++ проекта на python, то как-то не очень хорошо будет наворачивать хитрые операции со списками без острой необходимости. Напишите вместо одной строки три, пять и даже больше, но пусть Си-программист, знающий о питоне только то, что код на блоки там делится табуляцией, а не "{...}" сможет легко подправить ваш код.
5. Системы контроля версий. Иногда посещает мысль, что за коммиты без комментариев или с комментариями без смысла надо «наказывать. Жестоко наказывать». Сэкономили минуту, потом скорее всего сами будете несколько часов разбираться, что же изменилось с последнего релиза.
Редкие коммиты — еще то свинство. Обычно народ оправдывается, что не хотел ломать общий код пока все не отладит. CVS уже почти никто не пользуется, а в современных средствах начиная с SVN есть те или иные средства создать ветку для ваших опытов.
Уфф. Выпустил пар. Пошел дальше исправлять очередного С#-ного монстра.
Целью автора было не желание устроить очередной спор на тему «пишут ли комментарии настоящие программисты». Скорее просто обратить внимание на очевидные вещи, о которых многие знают, но почему-то забыли.
— assembler (ARM, ADSP-21xx)
— embedded C (IAR for ARM)
— обычный C (gcc for Win)
— C++ (gcc и MSVS for Win)
— C#
— python (скрипты для сборки, кодогенерация)
Мне всегда нравилось приводить в порядок чужой код, исправлять чужие баги. Не как основная работа, а как некоторая разминка для ума плюс хороший способ научиться другому подходу, нежели чем привычный, к разработке (в последних крупных проектах помимо руководства и программирования я взял на себя и задачу исправления ошибок — получилось эффективнее, чем у непосредственных разработчиков). Но так как теперь это большая часть основной работы, некоторые моменты начали раздражать.
Основная проблема в том, что как оказалось многие забыли или просто не задумывались об одном из основных принципов разработки — KISS (Keep It Simple Stupid).
Как это проявляется:
1. Выражения и приоритеты операций. Многих еще в ВУЗе плотно гоняли на курсе программирования по приоритетам операций. Часто до такой степени, что даже если разбудят посреди ночи — сходу расскажешь все приоритеты операций языка Си. В итоге код, который генерируют такие деятели является готовыми задачами для курса программирования. Но реальный код пишется не для экзамена!
Когда в выражении три-четыре операций при беглом просмотре разобраться не сложно, но когда их уже пять-шесть — начинаешь притормаживать, семь и больше — начинает отвлекать от более глобальных вещей. Расставьте скобки — никто вас за это уважать не перестанет, а тот кому придется потом во всем разбираться (возможно это будете вы сами через несколько лет) только спасибо скажет.
Длина выражения должна быть такой, чтобы сразу было понятно, что происходит. Как вам такой код:
if (flag_)
T_sync = (T1MR1 - old_T1CR0) + ((ovf_count > 0) && (adding_was == 1) ? (T1CR0_val - T1TC_dt_old) :T1CR0_val) + (ovf_count > 1 ? (ovf_count - 1) * T1MR1 : 0);
Я обычно на таком подвисаю на несколько минут и, по опыту, обычно в таких выражениях и нахожу ошибки. Разбить выражение на несколько несложно, нормальный компилятор потом все равно оптимизирует, а разбираться будет куда легче, да и вероятность ошибки упадет в разы.
2. Комментарии. Не буду капитаном очевидностью разглагольствуя на тему «в коде должны быть комментарии». Дело тут в другом:
— когда пишите комментарии хоть чуть-чуть думайте, как их будут понимать другие люди или вы сами через пару лет
— бессмысленные комментарии только отвлекают от чтения кода
— если поправили код — поправьте комментарии (вот за такую лень пару раз хотелось просто убить, а один раз разработчик при мне сам на этом попался) так, чтобы было соответствие коду
Я уже давно сначала пишу комментарии (по сути псевдокод-описание алгоритма), а потом уже кодирую. Реально помогает. И кодируется быстрее, и ошибок меньше, и поддерживать такой код потом проще. А если сразу писать комментарии так, чтобы потом можно было все скормить doxygen'у (или подобному средству), то вам потом не раз спасибо скажут…
3. Форматирование. Каждый привык к определенному виду форматирования исходных текстов. Количество сломанных копий в спорах на тему лучшего способа оформления Си-кода уже наверное не поддается подсчету. Я спокойно отношусь к тому, что способ форматирования в коде, в котором разбираюсь отличен от удобного мне, но наплевательское отношение к форматированию раздражает очень сильно. Я конечно могу запустить justifier, но почему бы самому разработчику это не сделать, если лениво сразу код красиво писать?
4. «Я мастер <Си, python, C++ и т.д.> и мой код должны читать опытные люди». Может за это мне и наставят минусов, но иногда стоит думать о том, что ваш код может поддерживать человек, который не так хорошо владеет (а может вообще не владеет) доступными вам технологиями и написать его максимально упрощая.
К примеру, если вы пишете скрипт сборки релиза Си/С++ проекта на python, то как-то не очень хорошо будет наворачивать хитрые операции со списками без острой необходимости. Напишите вместо одной строки три, пять и даже больше, но пусть Си-программист, знающий о питоне только то, что код на блоки там делится табуляцией, а не "{...}" сможет легко подправить ваш код.
5. Системы контроля версий. Иногда посещает мысль, что за коммиты без комментариев или с комментариями без смысла надо «наказывать. Жестоко наказывать». Сэкономили минуту, потом скорее всего сами будете несколько часов разбираться, что же изменилось с последнего релиза.
Редкие коммиты — еще то свинство. Обычно народ оправдывается, что не хотел ломать общий код пока все не отладит. CVS уже почти никто не пользуется, а в современных средствах начиная с SVN есть те или иные средства создать ветку для ваших опытов.
Уфф. Выпустил пар. Пошел дальше исправлять очередного С#-ного монстра.
Целью автора было не желание устроить очередной спор на тему «пишут ли комментарии настоящие программисты». Скорее просто обратить внимание на очевидные вещи, о которых многие знают, но почему-то забыли.