Clean Code
13.3K subscribers
2.31K photos
5 videos
2.97K links
Советы по написанию кода, обзоры распространенных ошибок и многое другое.

Ссылка: @Portal_v_IT

Сотрудничество: @oleginc, @tatiana_inc

РКН: clck.ru/3Ht6ch
加入频道
Functions Should Do One Thing

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

#functions
TODO Comments

Комментарии TODO.
Иногда бывает полезно ставить заметки "на будущее" в форме комментариев //TODO. Комментарии TODO напоминают о том, что, по мнению программиста, сделать необходимо, но по какой-то причине нельзя сделать прямо сейчас.
В следующем примере комментарий TODO объясняет, почему функция имеет вырожденную реализацию и что она должна делать в будущем.

#comments
Quicktype: generate code from Json

Quicktype - сервис для создания моделей и сериализаторов из JSON, для быстрой и безопасной работы с данными на любом языке программирования.
Если вам прислали огромный Json объект, то вместо создания модели самостоятельно вы можете просто воспользоваться данным сервисом.

Quicktype

#apps
Интересуешься разработкой игр? Тогда рекомендную заглянуть на наш второй проект.

Game Dev - канал о игровой индустрии, на котором публикуются статьи по геймдизайну и разработке игр, тематические новости и многое другое.

Сделай игровую индустрию лучше @GameDev
Kiss: Keep It Simple, Stupid

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

#principles
Start with try-catch-finally

Начните с try-catch-finally.
Размещая код в секции try-catch-finally, вы утверждаете, что выполнение программы может прерваться в любой точке, а затем продолжиться в секции catch. Секция catch должна оставить программу в целостном состоянии, что бы ни произошло в секции try. По этой причине написание кода, который может инициировать исключения, рекомендуется начинать с конструкции try-catch-finally. Это поможет вам определить, чего должен ожидать пользователь кода, что бы ни произошло в блоке try.

#exceptions
Command Design Pattern

Command Design Pattern: позволяет инкапсулировать запрос на выполнение определенного действия в виде отдельного объекта. Этот объект запроса на действие и называется командой. При этом объекты, инициирующие запросы на выполнение действия, отделяются от объектов, которые выполняют это действие.

#designpatterns
Do not pass null

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

#functions #arguments
Follow Standard Conversions

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

#principles
Agile. Кросс-функциональные команды и самоорганизация

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

#architecture #principles
Avoid negative conditions

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

#conditions
Clean HTML

В статье представлены несколько простых и полезных советов по написанию кода разметки html, его структура, и то, на что действительно должна быть похожа разметка.

#html #css
Unambiguous Names

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

#naming #functions
Agile: Кросс-функциональные команды и самоорганизация. Part2

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

#architecture #principles
Flags in Arguments

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

#functions #arguments
Lack of Tests

Недостаток тестов. Сколько тестов должен включать тестовый пакет? К сожалению, многие программисты руководствуются принципом "Пожалуй, этого хватит". Тестовый пакет должен тестировать все, что может ломаться. Если в системе остались условия, не проверенные тестами, или вычисления, правильность которых не подтверждена, значит, количество тестов недостаточно.

#tests
YAGNI

YAGNI — процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.

#architecture
Agile: Кросс-функциональные команды и самоорганизация в основе Agile. Part3

В предыдущей статье из цикла мы разобрались с понятием кросс-функциональных команд, "официально" привнесённым в мир Agile фреймворком Scrum, и постарались донести их преимущество относительно традиционного деления по "зонам ответственности". Но теперь перед нами обязательно встает вопрос - как организовать работу всей команды...

#agile #scrum