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

Вот 12 советов по написанию кода, который поможет вам и другим.

1. Используйте линтеры.

Линтеры поддерживают согласованность кода. Это помогает сделать структуру кода одинаковой для всех команд разработчиков, чтобы не было путаницы между разработчиками. Линтеры также охватывают отступ кода, использование правильных переменных, лучшие современные практики и т. д. Я, разработчик JavaScript, использую такие линтеры, как ESLINT, JSLINT, JSHINT и т. д. Похожие типы линтеров доступны для Python, Java и почти всех популярных языков программирования. Эти линтеры легко сочетаются с вашими текущими редакторами кода, такими как VSCode, Atom, Sublime text и другими полнофункциональными IDE, такими как Intellij, PHPStorm, WebStrom и т. д.

2. Отдавайте предпочтение высокому сплочению и слабому взаимодействию.

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

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

Это нетехнический критерий, о котором следует помнить при написании кода. Написание кода низкого качества — это не технический долг. Если вы работаете над сольным проектом или проектом, у которого нет дедлайна, вы можете пропустить этот пункт, но если вы работаете на кого-то или в какой-то компании, то планируйте свое время и работайте со своей стороны. Запланируйте время на планирование, написание кода, тестирование и обзоры соответственно. Если вы этого не сделаете, то в вашем проекте чего-то точно не будет.

4. Программа с намерением.

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

5. Избегайте примитивной одержимости.

«It is better to reuse than to rewrite» — всегда помните об этом. Старайтесь не переписывать функции, классы или любые фрагменты, которые уже доступны в кодовой базе. Эти методы очень эффективны, а также написаны одним из лучших разработчиков. Если вы считаете, что ваш метод может превзойти эти предопределенные методы, тогда потребуется значительная переработка, но помните, что это очень маловероятно.

Например -

для сортировки массива в java вам не нужно каждый раз писать алгоритмы сортировки, вы можете просто использовать Arrays.sort(ArrayName).

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

Примечание. Функциональное программирование › Императивное программирование.

6. Всегда предпочитайте чистый код, а не умный код.

Написание умного кода заставляет вас чувствовать себя хорошо, и вы не одиноки. Это дает вам момент радости и уверенности. Есть цитата — «Programs must be written for people to read and only incidentally for machine to execute». Я хочу, чтобы вы запомнили эту цитату в следующий раз, когда будете писать умный код. Я хочу сосредоточиться на одном основном недостатке, написав умный код. Ну понятно, что вы не запомните каждую строчку кода, которую вы написали. Возможно, через пару месяцев вы даже не вспомните, как работали над проектом. Итак, если вам нужно изменить часть кода или, возможно, вы хотите добавить функцию, вам нужно вернуться и прочитать тот же умный код, который вы написали несколько месяцев назад. Этот код определенно запутает вас и займет большую часть вашего времени. Чтобы избежать таких сценариев, мы должны избегать написания умного кода.

7. Примените принцип Цинссера.

«Трудно писать — легко читать, а легко писать — тяжело читать» — Zinsser’s Principle. Итак, чтобы прояснить это, не торопитесь кодировать. Подумайте о чистом и простом способе написания кода, чтобы другим и вам в будущем было легче читать его, не застревая и не тратя слишком много времени. Я также хотел бы предложить всем оставлять пустую строку после каждого объявления функции, определения класса или любого акта релевантности перехода. Это делает чтение кода очень простым, а переходы и разрывы понятны всем.

8. Комментируйте почему, а не что.

A good code is like a good joke, it’s not worth it if you have to explain it. Всегда комментируйте только логику кода. Попробуйте написать выразительный самодокументирующийся код. Прокомментируйте, почему код не делает то, что делает этот код.

Например:

i++; // post increment i value by one

комментарии такого типа глупы, поэтому, пожалуйста, избегайте их. Скорее объясните, почему приращение сделано.

9. Избегайте длинных методов.

При написании методов применяется SLAP (принцип единого уровня абстракции). Вы можете догадаться, почему разработчики не предпочитают длинные методы. Лично мне не нравятся длинные методы, потому что их сложно поддерживать, трудно отлаживать, сложно тестировать и еще сложнее рефакторить. Длинные методы имеют высокую связанность и низкую связность, они не подходят для повторного использования, а длинные методы приводят к дублированию кода. Они нарушают хорошие принципы кодирования. Итак, отделите метод, когда вы считаете, что его уровень абстракции завершен.

10. Соблюдайте соглашения об именах.

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

Например -

int a , b, c;

Никогда не делайте этого. Эти переменные не объясняют, что они делают. Они усложняют программу и создают больше путаницы. Для классов не забудьте назвать их инициалы заглавными буквами. Для метода и переменной вы можете использовать snake_casing или CamelCasing.

11. Используйте тактические проверки кода.

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

12. Уменьшите состояние и мутации состояния.

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

Надеюсь, вам все нравится :)