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

Был поздний вечер.

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

Код работал.

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

Люди, по своей природе, склонны к совершению ошибок. Однако множества недочётов, характерных для разработчиков, можно избежать. Если программист способен избавиться от распространённых оплошностей, о которых речь пойдёт в этом материале, он сможет писать более качественный и чистый код.



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

Вот некоторые распространённые недочёты, которых стоит избегать программисту.

На прошлой неделе создатель Dicey Dungeons Терри Кавана отпраздновал десятую годовщину своей давней игры VVVVVV, by опубликовав её исходный код [перевод на Хабре]. Если объяснять просто, то это значит, что любой человек может теперь посмотреть, как создавалась игра, потому что каждую строку кода можно внимательно изучить.

Такое нечасто случается и поэтому ценность публикации этой информации очень велика. Люди могут учиться по ней или улучшать код. Некоторые отзывы на исходный код VVVVVV были ужасными — исследователи увидели вещи, которые можно было написать лучше. Возможно, Кавана предвидел это — в своём посте, где он объявил о публикации кода, Терри признаёт, что «технически игра VVVVVV не очень хорошо продумана! Даже по стандартам инди-разработчиков-самоучек, код довольно хаотичен».

Существует заблуждение, что написание кода само по себе является изящным и продуманным, ведь в конечном итоге, это своего рода написание логики, не так ли? Не зря ведь это называется компьютерными НАУКАМИ? Но в реальности всё гораздо сложнее. Очень часто истории разработки видеоигр показывают, что поскольку в играх есть так много элементов, от геймдизайна до звука, что часто собираются в единое целое только в последний момент, если вообще когда-нибудь собираются.

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

Но если в алгоритме комбинируются разные методы, то тогда он относится к классу гибридных сортировок.

Примечание переводчика: в текущий момент я подготавливаю материалы для обещанной статьи по монадам. К сожалению, это занимает довольно много времени, не говоря о том, что я всё же должен заниматься основной работой и уделять время семье, но процесс идёт. А пока представляю вам перевод небольшой свежей заметки от замечательного товарища Mark Seemann'а, которая мне показалась любопытной.

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

Церемонность

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

Церемония — это то, что вы делаете до того, как начнете делать то, что вы действительно собирались сделать.

Venkat Subramaniam

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

Это привело меня к мысли о том, что существует злосчастная Зона Церемонности:

Конечно же, эта диаграмма всего лишь упрощение, но я надеюсь, что она демонстрирует суть. C++, Java и C♯ — языки, которые требуют церемонности. Справа от них находятся языки, которые мы могли бы назвать транс-церемониальными, включая F♯ и Haskell.

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

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

Чтобы понять принцип действия этой «многополосной» сортировки проще для начала разобраться на примере флага с тремя полосами. А чтобы легко разобраться с трёхцветным флагом, лучше сначала посмотреть, как это работает на примере двухцветного. А чтобы разобраться с двухцветным...

Вы наверняка слышали это знаменитое высказывание от GoF: «Предпочитайте композицию наследованию класса». И дальше, как правило, шли длинные размышления на тему того, как статически определяемое наследование не настолько гибко по сравнению с динамической композицией.

Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования тоже проблемы. «И что же теперь, не использовать наследование вообще?» – спросите Вы.

Давайте посмотрим на то, как сильная зависимость между классами через наследование может сделать архитектуру вашей системы чрезмерно жесткой и хрупкой. И зачем использовать одно из самых загадочных и неуловимых в коде ключевых слов – final. Сформулированные идеи демонстрируются на простом сквозном примере. В конце статьи приведены приемы и инструменты для удобной работы с final классами.

Проблема хрупкого базового класса

В этой статье я расскажу о новой библиотеке (и утилите) статического анализа go-ruleguard, которая адаптирует gogrep для использования внутри линтеров.

Отличительная особенность: правила статического анализа вы описываете на особом Go-подобном DSL, который на старте ruleguard превращается в набор диагностик. Возможно, это один из самых легко конфигурируемых инструментов для реализации кастомных инспекций для Go.

В качестве бонуса, мы поговорим об go/analysis и его предшественниках.

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

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

Давайте разберём несколько важных принципов создания самодокументируемого кода.

Привет, Хабр! Представляю Вашему вниманию перевод статьи «6 Tips To A Successful Code Review».

Сode review во все времена являлся основополагающей практикой, отвечающей за создание чистого и поддерживаемого кода.

Частенько разработчики пренебрегают и недооценивают code review по причинам, которые кажутся в тот момент объективно правильными.

Давайте сегодня сформулируем 6 советов, чтобы провести качественный и плодотворный code review.

Привет, Хабр!

В статье я хочу рассказать о нашем опыте создания своих запросов в Checkmarx SAST.

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

Мы разберемся в тонкостях языка запросов Checkmarx SAST и напишем 2 запроса для поиска SQL-инъекций и Insecure Direct Object References.

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

В Python много отличных доступных «из коробки» модулей. Один из самых полезных — collections. Он содержит «специализированные типы для создания контейнеров», являющихся альтернативами универсальным dict, list, set и tuple. Ниже мы рассмотрим три содержащихся в модуле класса, с которыми большинство питонистов сталкивались, но постоянно забывают применять на практике.

Функциональное программирование — это очень забавная парадигма. С одной стороны, про неё все знают, и все любят пользоваться всякими паттерн матчингами и лямбдами, с другой на чистом ФП языке обычно мало кто пишет. Поэтому понимание о том, что же это такое восходит больше к мифам и городским легендам, которые весьма далеко ушли от истины, а у людей складывается мнение, что "ФП подходит для всяких оторванных от жизни программок расчетов фракталов, а для настоящих задач есть зарекомендовавший себя в бою проверенный временем ООП".

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

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

Чаще прочих встречается вот такая алгоритмическая идея.

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

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

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

Дисклеймер: нижеизложенное — исключительно моё субъективное мнение.

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

Меня зовут Дмитрий Шехтман, и я автор самых маленьких компьютерных шахмат в мире.

Началось всё с того, что моя (ныне бывшая) девушка предложила написать компьютерные шахматы. Идея меня заинтересовала, и я решил этим заняться. Правда, почитав интернет, я понял, что опоздал лет на сорок. Особенно впечатляли шахматные разработки Оскара Толедо — на Си размером в 1257 байт, на JavaScript в 1023 байта и, наконец, Atomchess на ассемблере x86, компилирующийся в 392 байта.

Прежде, чем я вернулся к теме, прошло несколько месяцев. Как оказалось, за это время был установлен новый рекорд размера — ChesSkelet для ZX Spectrum занимал всего 352 байта. Правда, он не знал всех правил и играл весьма слабо, но всё же! А не замахнуться ли мне на шахматы на ассемблере? — подумал я.

Оптимизирующие компиляторы — основа современного ПО: они позволяют программистам писать код на понятном для них языке, затем преобразуя его в код, который сможет эффективно исполняться оборудованием. Задача оптимизирующих компиляторов заключается в том, чтобы понять, что делает написанная вами входная программа, и создать выходную программу, которая делает всё то же самое, только быстрее.

В этой статье мы рассмотрим некоторые из основных методик приведения (inference techniques) в оптимизирующих компиляторах: как спроектировать программу, с которой компилятору будет легко работать; какие приведения можно сделать в вашей программе и как использовать их для её уменьшения и ускорения.