Написание красивого кода часто недооценивается, особенно неопытными разработчиками. Главные причины состоят в том, что написание красивого кода занимает больше времени, и Вы не будете видеть его преимуществ сразу же.
Что такое красивый код?
Красивый код является чистым, хорошо организованным, и который легко обновить. Легко читать, понять, и перейти. Чтобы создать и поддержать такой код, я следую этим восьми простым принципам.
1. Имейте стандарты кодирования
Кодирующие стандарты являются рядом правил кодирования. Нет никакого универсального стандарта кодирования, у каждой команды продукта могли бы быть свои собственные записанные и незаписанные правила. Среди важных я упомянул бы инструкции для
именования переменных и именования методов,
как к групповым методам и как сгруппировать классы,
порядок методов записи,
как импортировать зависимости,
как хранить данные. Таким образом, у Вас был бы единый кодекс в каждом классе.
Этот вид кода более удобен для понимания. Кодирующие стандарты дают Вам непротиворечивость во всех проектах, Вы работаете. При рассмотрении некоторого проекта от компании впервые Вы будете знать, где искать содержание, которое Вам нужно. В долгосрочной перспективе кодирующие стандарты сохраняют для Вас много времени — от рассмотрения кода к обновлению функций.
Давайте посмотрим некоторые хорошие и плохие примеры именования переменных и методов:
КАРТИНКА
Теперь еще один пример Делает и не Делает для того, чтобы нащупать Ваши методы:
КАРТИНКА
Кроме того, при разговоре о кодировании стандартов не забывайте организацию рабочей области. Для навигации быстро необходимо организовать проект функционально: создайте группы файлов, которые касаются друг друга. Сохраните ту же организацию по всем проектам. Таким образом, если Вы работаете над несколькими проектами, у Вас нет проблем с нахождением ресурсов, которые Вы хотите.
2. Используйте собственные записи
Во-первых у Вас есть ясная перспектива, что глобально и что является локальной переменной для текущей области. XCode Allthow выбирает различный цвет для глобальных переменных, который не является достаточно хорошим различием для меня. При использовании свои записей, намного легче распознать код.
В другой руке, если у Вас есть код со многими обработчиками, необходимо использовать свои записи в них. Используя его за пределами обработчиков это делает Вашу универсальную форму кода.
3. Используйте метки более легкой навигации
Отметки используются для деления функциональности в значимые, легко перемещаемые разделы. И все же, не все разработчики используют их. Существует два типа меток с точки зрения предварительного просмотра с и без тире (-).
КАРТИНКА
Мы используем метки с десятью кубометров для создания разделов, и если Вы хотите создать подгруппы, мы используем метки без тире.
Снова, как в первом разделе, этот код легче понять, переместиться, и рассмотреть. Код без меток или методов, помещенных в неправильный раздел, не должен быть утвержден в обзоре.
4. Константы
Не должно быть никаких последовательностей или любой другой константы в Ваших классах. Константы являются сведениями, которые не имеют большого количества значения, таким образом, Вы не должны обращать внимание на него. Кроме того, они могут быть довольно длинными на другом языке, таким образом, он делает Ваш код нечитабельным.
То, что необходимо сделать, должно создать файл с константами, создать стандарт кодирования для именования констант, сгруппировать их использующий метки, и затем использовать их в классах. Еще одно преимущество констант - то, что можно снова использовать их, и если существует потребность в изменении, существует только одно место, чтобы сделать это.
5. Размер класса
Необходимо предопределить размер класса. Идеально, класс не должен быть более длинным, чем 300 строк без комментариев, но будут исключения, конечно. Маленькие классы намного легче понять, справиться с ними, и изменить их.
Для имения маленьких классов сначала необходимо думать об архитектуре. В стандартном MVC трудно иметь контроллеры, которые меньшего размера, чем 300 строк. Вот почему необходимо попробовать другими типами архитектуры как MVVM или Viper. Там, контроллеры не являются настолько крупными, потому что они только ответственны за логику представления. Бизнес-логика находится в других файлах.
Однако знайте. Удобочитаемость должна всегда быть приоритетом относительно размера класса. Ваши функции должны также быть небольшими, легкими для чтения и понимания. У Вас должно быть максимальное количество строк для функции, и если функция имеет больше строк, чем позволенный, необходимо осуществить рефакторинг его. Давайте посмотрим на практике:
КАРТИНКА
6. Создайте допускающее повторное использование компонента
Еще один прием для того, чтобы легче понять классы - нужно создать допускающее повторное использование компонента со следующими характеристиками:
1. Это обрабатывает бизнес-процессы
2. Это поможет получить доступ к другому компоненту
3. Это относительно независимо от программного обеспечения
4. Это несет только одну ответственность
Импортируйте те компоненты в других классах.
7. Шаблоны разработки
Для решения некоторых проблем уже существуют отличные решения — шаблоны разработки. Каждый шаблон похож на проект, который можно настроить для решения конкретной проблемы в коде, и после определенной практики, довольно легкой понять и реализовать. Шаблоны разработки делают связь между разработчиками более эффективной. Профессионалы программного обеспечения могут сразу изобразить высокоуровневый дизайн в головах, когда они обращаются к названию шаблона, используемого для решения специфического вопроса.
Для каждого приложения нужен различный набор шаблонов, но существуют общие — делегация, наблюдатель, фабрика, внедрение зависимости.
8. Обзор кода
В то время как основная цель обзоров кода должна быть функциональностью, мы также должны заботиться об удобочитаемости и организации кода. Если код не компилирует в эти принципы, отклоните запрос получения по запросу.
Некоторые инструменты могут помочь Вам с обзорами кода как SwiftLint или Tailor, таким образом, я настоятельно рекомендую использование того.
Обзоры кода могут занять время, но это - инвестиции для будущего. Новые разработчики изучат эти принципы путем рассмотрения кода, и путем получения обратной связи про них. Кроме того, чистый код сэкономит Вам время, когда Вы возвратитесь для изменения функции после нескольких месяцев.
Будьте строги при рассмотрении и ожидайте того же от других при рассмотрении кода. Не объединяйте код, если он имеет дефекты.
Заключение
Функциональным аспектом кода является основная часть разработки приложения. Однако, чтобы легко поддержать и обновить приложение, код должен быть чистым, организованным, легким для прочтения, понятия, и перехода, или как мы назвали его здесь красивым.
Это принципы, которые я использую для создания моего кода красивым.п