«Поверните налево, идите прямо и затем поверните направо. Вы найдете больницу справа от вас, затем поверните налево, снова налево, как только вы заметите дерево справа от вас …… .. »Подождите, что ?!

Теперь взгляните на изображения ниже. Кого из них ты бы дважды нажал на insta и heart на фейсбуке?

Большинство из нас предпочло бы изображение справа, а не слева.

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

Вот что означает "беспорядок" на жаргоне программирования:

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

С другой стороны, чистый:

Полная противоположность этому. Разборчиво, а значит, с ним легко работать.

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

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

Время рассказов!

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

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

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

Я не мог расшифровать свой собственный код - действительно, я сам вырыл себе могилу! Я даже не буду вдаваться в подробности того, что происходило в контроллере, в модели или в файлах вида!

Я слишком боялся удалять какие-либо строки кода, потому что боялся, что в пятницу вечером я должен был поместить их туда по какой-то причине!

Именно тогда я осознал важность чистого кода, что впоследствии позволило мне сэкономить много времени и энергии, как и для многих других программистов.

Давайте поговорим о коде прямо сейчас

Работая над фреймворком MVC, мы как-то путаем цель использования самого фреймворка. Согласно моим гуру - stackoverflow, quora и т. Д., Модели в MVC должны использоваться для извлечения данных из БД, контроллеры для обработки логической части, файлы Blade для представления дизайна миру и так далее. Но когда дело доходит до выполнения задачи вовремя, мы часто терпим неудачу, потому что ошибаемся, написав грязный код, который позже станет стогом сена.

Пригодился ряд уловок. Чтобы сузить круг вопросов, вот четыре вещи, которые мне больше всего помогли:

1. Именование переменных / методов / классов:

Присвоение имени дочернему элементу (переменные / классы и т. Д.) Имеет решающее значение, потому что ребенок будет узнаваться на протяжении всей своей жизни (на протяжении всего проекта) именно по этому имени. Скажем, мне нужно объявить 3 переменные, поэтому я использую

variables => $cake1, $cake2, $cake3

Ух ты, у меня есть 3 торта, спаси меня Бог от диабета… ммммм .. плохая шутка, моя плохая. По этим именам многого не уяснишь. Хорошее наименование было бы,

variables => $tea_cake, $birthday_cake, $anniversary_cake

Круто, правда? Сами имена говорят о предназначении торта. То же самое касается имен классов и имен методов (функций). Рассмотреть возможность

function names => get_me_car()
buy_me_car()

Это неоднозначно. Так что я бы импровизировал, например:

function names => book_my_cab()
buy_me_mercedes()

Яснее, не правда ли? То же самое и с «Названием классов». Не бойтесь, если потребуется, немного многословно назвать свои имена. Ясность предшествует многословности.

2. Код форматирования:

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

Программно, взяв несколько подсказок из приведенного выше примера, было бы элегантно, если бы я,

⦁ поставить один пробел до и после «=» (операторов) в логической части

⦁ пробел для "{" после имени функции, или фигурные скобки могут указывать на следующую строку.

⦁ последовательный отступ - убедитесь, что операторы for loop и if начинаются и заканчиваются на одном и том же отступе с равными пробелами.

⦁ Равные линии разрыва между двумя функциями.

⦁ Равные пробелы для новой строки кода, я предпочитаю 4 пробела (т.е. 1 табуляция)

⦁ Максимальное количество символов в строке (80 в стандартной комплектации)

⦁ Классы с минимумом строк, наилучшим образом выполняющие свою работу.

⦁ Группирование деклараций функций, их определение и размещение в разных местах.

⦁ Лучше избегать «глубокого гнездования» - кружится голова :(

⦁ Использование «snake_case» или «CamelCase» на протяжении всего проекта.

Есть еще много стандартов, которым вы можете следовать, но вышеупомянутые пункты - несколько хороших для начала.

3. Небольшие функции с одной задачей - модульность:

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

Рассмотрим этот пример: -

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

И если мне нужна функция, которая немного отличается, но выполняет то же самое, следует ли мне написать еще одну функцию?

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

Простое решение:

Чтобы упростить запутанный код, я резюмировал функцию. Это оказалось полезным при переработке кода.

Чистый код:

Многое ясно и просто, правда ???

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

4. Комментарии для разъяснения:

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

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

Но почисти немного:

Было бы лучше, если бы я удалил комментируемые строки - возможно, переменная объявлена ​​и не используется, некоторая логика, используемая ранее, условия, применяемые для запросов к БД, но не используемые на более поздних этапах программы.

Это необходимо для ясности другим разработчикам. Итак, убедитесь, что вы удалили ненужные коды.

Forward Clean Code также включает «Организация файлов и папок». Я использую Visual Studio Code во время работы над Laravel. Laravel уже структурирован так, чтобы отдельно размещать файлы контроллеров, моделей, блейдов, изображений и т. Д. Но когда я сталкиваюсь с задачей, в которой нужно сделать несколько вещей, я предпочитаю организовывать файлы с задачами отдельно.

Скажем, например, на Highape.com, когда пользователь входит в систему / регистрируется, мне нужно проверить, является ли он новым пользователем или старым пользователем. Если он новый пользователь, мне нужно сохранить все его данные в нашей базе данных SQL и отправить ему приветственное письмо. В случае, если он старый пользователь, мне нужно проверить, обновил ли он свою информацию, если да, мне нужно обновить ее в нашей базе данных SQL.

Итак, вместо того, чтобы писать все в одном контроллере, я разбил вещи следующим образом:

check if new user -> update and send mail
check if old user -> did he update any detail? -> No -> Move ahead
check if old user -> did he update any detail? -> Yes -> Update Detail

Представление блок-схемы варианта использования (диаграмма движется только вниз)

Итак, задача отправки электронной почты (которая отличается от обновления деталей) была записана в другом файле в папке с именем «Работа» (единственная задача которой - отправлять почту).

Это сделало мой код меньше и независимым, и «Задания» можно было снова использовать, когда мне нужно отправить почту (возможность повторного использования).

Завершение:

Практика чистого кода имеет много преимуществ: его легче начать и продолжить, проще следить, понимать и обновлять. Самое главное, приятно видеть, что ваши коды аккуратны и хорошо работают. Это само по себе стоит усилий!

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

Вы также можете связаться со мной в LinkedIn и подписаться на меня на GitHub.

Удачного кодирования :)