Почему важно писать хороший код и как это делать

При написании кода на любом языке есть хорошие методы кодирования - и есть действительно плохие.

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

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

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

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

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

Все начинает идти наперекосяк, когда художник не может понять собственное произведение искусства!

Ключевые моменты, о которых следует помнить при написании кода

Комментарии на помощь

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

Хорошие комментарии к коду объясняют, почему что-то сделано, а не то, что делается. Сам код объясняет, что делается. Необходимость в комментариях должна быть минимальной.

Отступ

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

README's

Когда перед вами кодовая база проекта, это раздражает, но на настройку и первое выполнение у вас уходит часы. Вот где пригодится README.

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

Соглашения об именах

Часто мы сталкиваемся с Class с именем Apimanager, но, глядя на имя, цель класса не ясна.

Согласно нормам передовой практики кодирования, наши классы должны следовать принципу единой ответственности (SRP). Правильные соглашения об именах в сочетании с SRP значительно облегчают нашу жизнь, когда мы пытаемся следить за проектом.

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

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

Избегайте магических чисел

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

В самом лучшем случае никто не знает, как число влияет на программу ... кроме того, что его изменение нарушает работу.

Магические числа - это зло, и их следует немедленно отменить.

Адаптация к таймфрейму

Картинка ниже говорит сама за себя.

Общие практики написания чистого, качественного кода

Написание кода хорошего качества - это динамичный процесс. Еще несколько моментов, которые следует учитывать при попытке написать хороший код:

  • Хороший код хорошо организован. Данные и операции в классах подходят друг другу. Между классами нет посторонних зависимостей. Не похоже на «спагетти».
  • Хороший код хорошо протестирован. Тесты служат исполняемой спецификацией кода и примерами его использования.
  • Хороший код - не умный. Он делает вещи простыми и очевидными способами.
  • Хороший код создается небольшими, легко читаемыми блоками вычислений. Эти единицы повторно используются в коде.

Спасибо за прочтение!