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

Условный оператор в обычной своей форме источником проблем является сравнительно редко. Однако само условие порой оказывается достаточно сложным и встает на пути к мечте любого разработчика. Речь, конечно же, о красивом и читаемом коде.

Возможно, я не там искал, но ни разу в стандартах оформления кода не встречал упоминаний о том, как быть со сложными условиями. Разобраться с ними — и есть цель данной статьи.

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

Меня давно интересует тема комментирования кода. Этот пост подвиг меня формализовать свою идеологию документирования кода.

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

Слова «описывать все описания » я написал неслучайно, ведь это почти то же что и

std::map<std::string, Person*>mapPPersonsNames //map person pointers by names

В последнее время, набирает популярность мысль, что комментарии в коде — дело не обязательное, и даже вредное. Буквально вчера вечером, общаясь со знакомым молодым программистом, попросившим посмотреть его код, я обнаружил, что комменты отсутствовали вовсе, даже привычные описания методов. На мой удивленный смайлик, был ответ: “Комментарии — первый признак плохого кода”. И черт бы с ним, с начинающим программистом, но я периодически читаю что-то похожее в блогах, и слышу от коллег. Может программирование в очередной раз сделало шаг вперед, а я, среди отстающих? Под катом, немного размышлений, о том, когда и почему стоит или не стоит комментировать свой код.

«Старая песня о главном»

«Стандарты именование объектов БД» и «правила оформления кода» темы не новые. Так или иначе, к вопросу выработки или заимствования таких стандартов и правил приходят все команды разработчиков. При желании в сети можно найти статьи и презентации по данной теме, а так же примеры и шаблоны различных соглашений. Многие из них безусловно полезны, некоторые — практически идеальны, если бы не одна маленькая оговорка: они написаны разработчиками и для разработчиков.

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

В принципе, пожелания по оформлению и именованию у «прикладника» (администратора приложения/технолога) и разработчика на 90 процентов совпадают. Но существуют все же некоторые отличия в восприятии «читателя» и «писателя», о которых я хотел бы поговорить.

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

К сожалению, во многих случаях авторы либо забираются в недосягаемые выси многослойных архитектур, что требуется в лучшем случае для 1% проектов, либо ограничиваются общими фразами вроде «код должен быть понятен» или «используйте ООП и паттерны», не опускаясь до подробных объяснений, в чем например измеряется «понятность» кода.

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

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


Паттерн не привязан к языкам программирования.

Update: Добавил пример из реальной практики.

Картинка для привлечения внимания:

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

Что такое НОД, все знают еще со школы. Для тех, кто подзабыл, напомню: НОД — наибольший общий делитель, делящий два целых числа без остатка. Например, НОД чисел 100 и 45 равен 5, а НОД чисел 17 и 7 равен 1. Существует несколько различных алгоритмов поиска этого числа. Однако, несмотря на то, что это достаточно простые алгоритмы, часто совершают одну маленькую, но очень существенную ошибку.

Это первый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

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

Я получил множество отзывов на мою недавнюю серию постов по Poka-yoke проектированию (я был бы расстроены, если было бы иначе). Множество из этих отзывов касаются различных технологий сериализации или трансляции, используемых обычно на границах приложения: сериализация, XML (де)гидратация (прим. переводчика: тоже самое, что и сериализация), UI-валидация и т.д. Заметьте, что такая трансляция происходит не только по периметру приложения, но также и на уровне сохраняемости (persistence). ORM-ы также являются трасляционными механизмами.
Общим для многих комментариев является утверждение о том, что большая часть технологий сериализации требует наличия конструктора по умолчанию. Например, класс XmlSerializer требует наличия конструктора по умолчанию и публичных, доступных для записи свойств. Большая часть объектно-реляционных преобразователей, которые я изучал, похоже, имеют те же требования. Контролы Windows Forms и WPF (UI – также граница приложения) почти обязаны иметь конструктор по умолчанию. Не нарушает ли это инкапсуляцию? И да и нет.

Это пятый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Конструкторы по умолчанию являются «запахом» в коде. Именно так. Это может звучать возмутительно

Это четвёртый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Недавно, я прочитал из какого-то технологического события Microsoft пост, написанный с энтузиазмом:

Атрибут [Required] в коде автоматически создаёт запись в БД, которая не может принимать null, а также создаёт валидацию на веб-странице – симпотично […]

Это третий пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Автоматические свойства – одна из наиболее излишних возможностей в C#. Я знаю, что многие люди очень их любят, но они решают проблему, с которой вы и сталкиваться не должны.

Это второй пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

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

От переводчика. Это перевод серии постов из блога Марка Симана. Я не хочу объединять некоторые из постов, несмотря на то, что они небольшие по размеру, а просто постараюсь соблюсти структуру, предложенную Марком.

Ещё немного от переводчика. POKA-YOKE можно перевести как «дуракоустойчивый» или отказоустойчивый.

Инкапсуляция является одной из самых недопонимаемых концепций в объектно-ориентированном программировании (ООП). Похоже на то, что большая часть людей думает, что, имеющая отношение к инкапсуляции, концепция «сокрытия информации», просто означает, что закрытые поля должны быть раскрыты через публичные свойства (или getter\setter-методы в языках, которые не обладают поддержкой свойств).

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

Сегодня мы снова возьмём за основу stupid sort и внесём в неё другое маленькое, но существенное изменение. В результате получим совершенного другой эволюционный ряд сортировочных алгоритмов.

image: эволюция

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

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

image: пузырьки

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

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

Написал правильную статью про проверку проекта Geant4. Напомню предысторию. Недавно была проверена старая версия библиотеки Geant4 и написана статья "Copy-Paste и мюоны". Почему была проверена старая версия? Люди не совершенны. Суть оплошности можно узнать в предыдущей статье. Теперь же вашему вниманию предлагается краткий отчет о проверке Geant4 версии 10.0-beta.

Сейчас я буду рассказывать и показывать на примерах, почему физики тоже должны использовать инструменты статического анализа кода. Мне бы хотелось, чтобы этим инструментом был PVS-Studio. Но, конечно, любой другой инструмент тоже будет полезен. Анализатор кода сократит время на отладку приложений и уменьшит головные боли от тупых ошибок. Лучше побольше думать о физике и поменьше об ошибках в программах на языке Си++.