Код — это «текст», написанный на одном из языков программирования. Программы для ПК, игровые проекты и веб-сайты работают по правилам, которые содержатся в коде. А он влияет на внешний вид, внутреннюю структуру. Еще код анализирует задачу и решает ее. Чистый код — это хороший код. Он написан просто и без излишеств, без дублей. Его структура построена так, чтобы его было легко читать и людям, и ПК. Далее мы рассмотрим основные правила написания кода, которые должны упростить работу разработчиков.
Общие принципы
Несколько принципов написания хорошего кода:
- Понятность и читаемость. Важно избегать слишком сложных проектов. Основная цель — простота и краткость. При создании программы или приложения важно помнить, что его придется еще как-то поддерживать, а значит, код должен быть понятным и очевидным даже для тех, кто не занимался его созданием.
- Единообразие и структурированность. Модернизация системы без нарушения основной структуры подразумевает то, что добавление или изменение одного элемента никак не повлияет на остальные. Также важно, чтобы каждая опция или каждый метод выполняли одну задачу.
- Избегание излишних комментариев. Если применять какие-то «костыли» или необычные решения, то нужно, чтобы эти решения дополнялись комментариями, чтобы стало понятно, почему было сделано таким образом. Лучше написать 1−2 строки комментария, чем заставлять людей думать, что это и зачем оно нужно. Но их не должно быть слишком много, комментарии даются лишь там, где это необходимо.
Именование переменных и функций
По соглашению программы C# применяют «Паскаль Кейс» для имен типов, пространства имен и всех открытых членов. Плюс команда dotnet/docs пользуется такими соглашениями (были приняты из стиля кодирования команды среды выполнения .NET):
- Названия интерфейсов начинают с большой буквы I.
- Все виды атрибутов заканчиваются «Attribute».
- Все виды перечисления применяют единственное существительное для нефлагов и множественное существительное для флагов.
- Идентификаторы не могут включать 2 последовательных символа подчеркивания (_).
- Выбирайте значимые и описательные имена для переменных, методов, классов.
- Лучше не применять имена с одной буквой, кроме простых счетчиков циклов.
- Ясность важнее краткости.
- Применяйте «Паскаль Кейс» для имен классов и методов, а также для имен констант, полей.
Использование CamelCase, snake_case и других соглашений
CamelCase — соглашение, при котором каждое слово, за исключением первого, начинается с заглавной буквы. Используется для именования переменных и функций во многих языках. PascalCase — соглашение, когда каждое слово начинается с большой буквы. Как правило, применяется для наименования классов.
Snake_case — соглашение, когда вместо пробела используется нижнее подчеркивание. Применяется, как правило, для имен полей баз информации, переменных и функций. Kebab-case — случаи, когда вместо пробела используется дефис. Применяется в URL и CSS. В языке «Лисп» таким образом пишутся все названия.
Оформление отступов и пробелов
Отступ может равняться 2 или 4 пробелам. Общее количество пробелов в 1-м отступе можно настроить в среде разработки. Как правило, для отступов используют 2 пробела, так как тогда код приобретает большую компактность.
- Горизонтальные отступы. Два или четыре пробела. Также можно выполнить при помощи символа табуляции (кнопка Tab).
- Вертикальные отступы. Пустые строчки для разбивки кода на «логические блоки». Даже одну опцию часто возможно разделить на части.
Окружайте бинарные операторы одиночными пробелами по обе стороны. Это правило можно отнести к присваиванию, операторам сравнения, булевым операторам. Особенности окружения пробелами операторов можно определять самостоятельно, как покажется правильным. В любом случае это должно сделать код более целостным.
Также следует выровнять код для улучшения читаемости. Как это сделать в HTML? Для выполнения выравнивания, как правило, применяется тег параграфа <p> с атрибутом align, от которого будет зависеть тип выравнивания. Кроме того, блок текста можно выравнивать при помощи тега <div> с таким же атрибутом align.
Комментарии и документация
Чтобы не перегружать интерфейсы класса информацией, документацию к методам разрешено выносить в файл с реализацией. При этом в блоках кода можно поставить лимит на количество строчек или слов в комментарии. Документацию можно вести в стандарте «Ява Док». Это комфортный формат, знакомый большинству IDE и поддерживаемый Doxygen’ом.
Общие рекомендации документирования:
- Создавайте документацию для того, что покажется «необычным».
- Приводите примеры использования кода.
- Если решение «необычное», опишите причины выбора.
- Попытайтесь отыскать золотую середину между отсутствием документации и комментированием каждой строчки.
- Не нужно пересказывать код.
Не забывайте о том, что ваши комментарии потом будут читать другие специалисты. Поэтому писать документацию нужно не ради проформы, а для упрощения работы собственной команды.
Как правильно писать Docstring? «Докстринг» сильно похож на комментарии, но его заключают в тройные кавычки. У всех опций должен быть «Докстринг», который включает описание работы конкретной функции. При этом комментарии, как правило, пытаются пояснить эту работу.
Избегание магических чисел и строк
Используйте названия константы с возможностью последующего поиска. Выбор однобуквенных имен для констант — не лучшее решение, потому что они могут появляться в разных местах, а значит, будет непросто их найти. Есть еще два важных правила:
- Использование константных переменных вместо хардкодинга.
- Вынос магических значений в настройки или конфигурацию.
Обработка ошибок и исключений
В «Питон» исключения обрабатывают при помощи блоков try/except. Для этого операция, которая может вызвать исключение, переносится внутрь блока try. А код, который должен реализовываться при появлении ошибки, находится внутри except.
В свою очередь, логирование представляет собой процесс создания логов, а точнее фиксацию и структурирование данных о функционировании системы в отдельные логовые файлы с возможностью мгновенного доступа к ним при необходимости. Логирование позволит следить за ошибками и анализировать их, а еще передавать важную информацию для настройки, поддержки приложения.
Оптимизация и производительность
Оптимизация построена на 3 «китах», среди которых естественность, производительность, потраченное время. Далее разберем каждую детальнее:
- Естественность. Код должен быть изящным, компактным и читабельным. Каждый модуль должен без проблем встраиваться в приложение. Код можно легко редактировать, отдельные опции можно быстро удалять или внедрять без необходимости серьезно менять прочие элементы программы.
- Производительность. На фоне оптимизации должен произойти прирост производительности ПО. Как правило, верно оптимизированное приложение повышает быстродействие хотя бы на 25−35%, если сравнивать с начальным вариантом
- Время. Оптимизация и последующая настройка должны занять минимум времени. В среднем, это срок в 10−20% от времени, которое было потрачено на написание продукта. В ином случае затраты себя не оправдают.
Тестирование кода
В модульном тестировании разработчики делают тестовые сценарии для отдельно взятых модулей для проверки правильности их работы. Если тестирование проходит неудачно, программисты выявляют и исправляют лаги до тех пор, пока не будет получен удовлетворительный результат.
Что применяется для автоматизации тестирования? Самыми востребованными инструментами можно считать: TestComplete, Selenium, Soap UI, QTP/UFT, UI Automator и прочие. В проектах немасштабных достаточно подобрать инструмент, написать автоматизированные скрипты, подготовить информацию для тестов и выполнить проверку. Это должно обеспечить бóльшую стабильность.
Версионирование и контроль версий
Версионирование — создание нескольких версий программы, которые обладают одними функциями (или улучшенными, или индивидуализированными), и управление ими. В целом, версия может рассказать о корректировках продукта. Самые популярные системы контроля версий: RCS, CVS, Subversion, Aegis, Bazaar, Arch, Perforce, TFS.
Какие системы контроля версий «Гит» можно применять в работе? Они могут быть локальными, централизованными или распределенными. Первая система хранит файлы на одном девайсе, вторая пользуется общим сервером, а последняя система использует общее облачное хранилище и локальные девайсы для членов команды.
Не стоит забывать и о том, что правильно оформленная история коммитов — это полезная и важная вещь. Тут могут прийти на помощь команды git blame, revert, rebase, log, shortlog и прочие. С правильно оформленной историей корректировок просмотр коммитов остальными программистами получает смысл.
Есть несколько правил хорошего описания коммита:
- Оставляйте пустую строчку между названием и описанием.
- Размер заголовка не должен превышать 50 символов.
- Начинайте заголовок с большой буквы.
- Не используйте точку в конце заголовка описания.
- Используйте повелительное наклонение в названии.
- Длина строчки в теле описания не должна быть больше 72 символов.
- В теле описания старайтесь ответить на вопросы «что?» и «почему?», а не «как?»
Это способ сделать историю изменений понятной, информативной, полезной.
Соблюдение языковых стандартов
Синтаксис в программировании представляет собой свод правил, которые поясняют, как писать код на определенном языке. Они отображают, как размещать и комбинировать друг с другом команды, какие символы применять, как делать понятную структуру и прочее.
В целом, синтаксис программирования устанавливает правила, применяемые для написания программного кода. Семантика определяет, каким образом код будет выполняться, а точнее, влияет на его значимость и поведение.
Если последовательность символов принадлежит языку, ее можно назвать синтаксически правильной. Для приложения это означает, что транслятор не показывает лаги или ошибки. Хотя синтаксическая правильность не может гарантировать ту же осмысленность продукта. То есть синтаксис определяет только одну сторону языка.
При этом стандартом кодирования называют перечень правил и соглашений, описывающих принципы оформления программного кода, который используется командой программистов совместно. Цель применения стандарта — упрощение понимания написанного кода человеком, снижение нагрузки на память и орган зрения во время чтения программного текста.
Почему стандарты важны для создателей сайта? Правильное оформление кода позволяет сократить срок создания сайтов, так как нет необходимости приводить элементы структуры к правильному формату. Нужно отметить, что программы-парсеры, у которых нет инструментов для внесения корректировок в шифр, не способны обрабатывать неправильную программу.
Много сообществ языков программирования уже создали общие стандарты. Например, если программист пишет код на C, то он можете выбрать стандарт GNU. Если работа ведется на «Руби», можно выбрать стандарт сообщества, который поддерживается Божидаром Бацовым. Но лучше, когда каждый проект вырабатывает собственный стандарт с учетом потребностей и личных предпочтений разработчиков.
