Качество кода *

 

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

Но давайте посмотрим на проблему с другой стороны. Что мы делаем, когда разбираемся с чьим-то кодом? Как происходит сам процесс изучения кода? Мы листаем функции, ищем определения переменных, классов, переходим от функции к функции, от файла к файлу.

На конференции HotDep 2012 Джерард Хольцман из Лаборатории реактивного движения НАСА прочёл лекцию о том, как обеспечивалась надёжность и корректность кода для марсохода Curiosity. Часовая лекция рассказывает, какие методики, стандарты кодирования и инструменты разработки применялись программистами НАСА, чтобы написать три с половиной миллиона строк сверхнадёжного кода, который в автономном режиме посадил Curiosity на поверхность Марса и обеспечивает работу всех его систем и приборов.

Лекцию можно посмотреть онлайн на сайте usenix.org, или скачать в формате .mp4 (228 Мб).

Грязный

Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?

Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код?


Давайте сначала разберёмся с определениями.

Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.

 

Успешный программный продукт обычно проходит за свою жизнь через руки множества разработчиков. Вы — лишь одно из звеньев в цепочке опекунов вашего проекта, и каждая строчка кода, которую Вы написали — это оставленный Вами артефакт, который когда-нибудь будет изучаться Будущим Разработчиком. Также, как Вы унаследовали решения разработчиков, которые были до Вас, другие разработчики унаследуют решения, которые Вы приняли сегодня. Они получают от нас в наследство все наши недоразумения, срезанные нами углы, примененные нами недопонятые паттерны и техники, наше невнимание к деталям, нашу лень, наши изменения, сделанные на скорую руку, наших скелетов в шкафах, наше грязное белье. И гораздо реже — выгоду от нашей дисциплинированности, наших обсуждений и подготовок.

Очередной спор о стиле, красоте и компактности кода занял слишком много времени, в связи с чем и был отправлен на разрешение широкой аудитории StackOverflow. Это помогло, и спор решился, но в комментариях мне намекнули, что я пришел не по адресу:

Stack Exchange's "codereview" site is the new hotness for this sort of question.

Оказывается, больше года назад в застенках Area 51 был рожден вопросник Code Review, призванный делать код лучше.

Внутренняя система инспектирования исходного кода Critic, применяемая в Opera Software, вчера вечером была выложена на Github под лицензией Apache License 2.0.

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

Скачать исходные коды Critic можно здесь: github.com/jensl/critic.

Всем привет! Сколько уже статей было про говнокод, но я считаю, их поток нельзя сокращать, потому как поток говнокода только увеличивается.
Внимание: статья полна субъективизма и сюрреализма. Автор не претендует на истину в последней инстанции
Очень часто, создавая новое приложение, программу, веб-сайт, мы сначала экспериментируем, а затем создаем из наших экспериментов конечный продукт.
Но дайте ответ на следующие вопросы не задумываясь:

1. сколько раз, получая исходники от других разработчиков, вы находили их крайне непривлекательными?
2. сколько раз, передавая исходники другим разработчикам вам было стыдно за свой код?

Мои ответы: постоянно, довольно часто.
Почему так происходит?

Думаю, никто не станет спорить, что хороший код — код, который не только исполняет, но и максимально описывает свою задачу (это, конечно, относится в первую очередь к бизнес-логике). Причем описывает ее не деталями алгоритма, а своей сигнатурой (названием, параметрами и возвращаемым типом), сигнатурой вызываемых методов, переменными, которые он использует. В таком случае тело метода можно прочитать сверху вниз, не удерживая в памяти какой-то дополнительный контекст.

Одна из вещей, которая делает классические русские романы столь тяжелыми для чтения (для иностранцев) это то, что главные герои имеют кучу имён. К примеру, в романе "Братья Карамазовы" один из персонажей — Алексей Фёдорович Карамазов (Alexei Fyodorovich Karamazov), которого по ходу текста называют также Алёша, Алёшка, Алёшенька, Алёшечка, Алексейчик, Лёша и Лёшенька (Alyosha, Alyoshka, Alyoshenka, Alyoshechka, Alexeichik, Lyosha и Lyoshenka)

«Программирование в стиле русских романов» — это антипаттерн, возникающий в ситуации, когда одна вещь имеет много имён. Для какой-нибудь программы у вас может быть путь в системе контроля версий, путь на диске, имя проекта, имя исполняемого файла и т.д. Все они могут иметь одинаковые (однокоренные) имена или наоборот — называться каждая по-своему. Например, синонимами. Или вообще разными словами. Так уж вышло по историческим причинам, что бинарник foo.exe получается при компиляции проекта bar, лежащего в папке baz и т.д.

Инспектирование кода — это очень сложная и ответственная задача, которая может отнимать много ресурсов. Важно ответственно подходить к инспектированию и проводить его эффективно. Эффективно — это значит тратить мало времени и находить много дефектов. Но как повысить эффективность? Ниже представлены несколько советов, которые помогут в этом.

Думаю, многие разработки знакомы с понятием code review или обзор кода по-русски (также данный термин переводят как просмотр кода, инспектирование кода или рецензирование кода – далее, для единообразия, будет использоваться вариант «обзор кода»). Недавно я столкнулся с необходимостью «разложить по полочкам» и классифицировать знания по этой теме. Результат – данная статья. Надеюсь, она окажется полезной, а также поможет внедрить обзоры кода в свой производственный процесс тем, кто только об этом задумывается.

Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).

Джофф Гарен (Geoff Garen) из компании Apple обнаружил вызов Sleep() в спинлоке функции TCMalloc сборщика мусора WebKit.

 -#if OS(WINDOWS)
-    Sleep(2);
-#else
-    struct timespec tm;
-    tm.tv_sec = 0;
-    tm.tv_nsec = 2000001;
-    nanosleep(&tm, NULL);
-#endif

После удаления Sleep производительность сборщика в определённых условиях выросла в 3,7 раза. Это наглядный пример, как одна маленькая оптимизация способна в несколько раз повысить производительность.

Привет, хабражители!

Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.

Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше…

На новой работе (С++) пришлось сменить привычный стиль кода, открывающие угловые скобки { надо было ставить на той же строке, что и начало блоков if/for etc. Поначалу было неприятно отказываться от старых привычек, но за неделю новый подход мне понравился. Тогда подумал — а вдруг существуют и другие аспекты стиля, которые надо изменить несмотря на то, что они пока еще кажутся непривычными? И несмотря на то, что большинство программистов по инерции их не использует. Оказалось, что так и есть. За пару месяцев я сильно переработал стиль, результаты ниже.

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

Cлышали ли вы об Open Source проектах, написанных на Java? А интересно ли вам узнать как они работают?



Если ваш ответ на последние два вопроса положителен, то неважно, слышали или нет вы о Queuepy до сих пор. Далее нам по пути.

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

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

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

Три дня и три ночи мастер не появлялся из своей кельи. На четвертый день монахи отправили послушника проведать его.

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

_{Две недели назад на Хабре публиковался перевод «Заблуждения программистов о времени», который по своей структуре и стилю основан на этом классическом тексте Патрика Макензи, опубликованном два года назад. Поскольку заметка о времени была крайне благоприятно воспринята аудиторией, то, очевидно, имеет смысл перевести и исходную статью об именах и фамилиях.}

Джон Грэхем-Камминг (John Graham-Cumming) сегодня жаловался в своём блоге, что компьютерная система, с которой он работал, не приняла его фамилию из-за недопустимых символов. Конечно, там нет недопустимых символов, потому что любой способ, как человек представляет себя, — по определению — является подходящим идентификатором. Джон выразил сильную досаду насчёт данной ситуации, и он имеет полное право, потому что имя — суть нашей индивидуальности, практически по определению.