Стиль кода, стиль программирования, соглашения о кодировании, рекомендации по кодированию, стандарты кодирования… - вы, должно быть, слышали или видели эти слова много раз и с тех пор. Правила, рекомендации, передовой опыт… собраны вместе для конечной цели - помочь команде создать профессиональную и хорошо читаемую базу кода. Звучит многообещающе, правда? Однако мне самому нелегко полностью применить стиль кода в реальном проекте.
Соглашения о кодировании действительно полезны и важны
Мы, разработчики, делаем все возможное, чтобы код работал, что, без сомнения, является для нас наивысшим приоритетом. Оптимизация кода и стилизация - это оставшиеся шаги, прежде чем мы сможем считать задачу выполненной. Без этих двух мы, скорее всего, отправим дерьмовый код. Все члены команды (включая нас самих, как это иронично!) И новички тоже пострадали бы от последствий.
Я сам был в такой ситуации. Несколько лет назад меня поместили в старый проект, чтобы исправить некоторые ошибки и добавить новые функции. Буквально через несколько часов после проверки кода мне сразу захотелось его выбросить! Приложение разрабатывалось четырьмя или пятью разработчиками в несколько этапов. Очевидно, никого из них не волновал рефакторинг и именование. Они оставили мне спагетти-код в различных стилях программирования плюс сотни предупреждений. С тех пор я стал уделять гораздо больше внимания удобочитаемости кода в своих проектах, полагая, что это улучшит качество моего кода.
Хорошее именование, хорошее использование функций языка помогают сократить объем кода для лучшего чтения и понимания кода. Уникальный стиль кода среди членов команды делает код проекта более чистым, следовательно, позволяет легче читать чужой код и облегчает интеграцию новых участников.
Внедрение всех правил - это трудоемкий процесс.
Соблюдение правил - не наш инстинкт
Мы не родились с набором правил. Это многолетний процесс для каждого из нас, чтобы получить высшее образование, научиться хорошим манерам и соблюдать законы нашего общества. В каждом обществе есть законы, которые лучше всего подходят его членам, поэтому нам, возможно, придется адаптироваться, если мы решим уехать за границу.
Точно так же, но в гораздо меньшем масштабе, в мире разработчиков мы не пишем наши первые строчки кода и не осваиваем лучшие практики одновременно. К тому времени мы можем даже не знать ни одного руководства по стилю. Действительно, во время учебы в университете я даже не знал, что этот термин существует. Я не один такой :) Однажды я поехал во Францию, чтобы продолжить учебу. Там я видел, как профессора давали упражнения по программированию, используя ключевые слова на американском английском (конечно) вместе с именами переменных на французском: D Если этому не учат в классах и не усваиваются собственными усилиями студента, нет сомнений, что он / она начнет свою карьеру с 0 стиль кода.
Мы испытываем разные версии соглашений о кодировании с разными командами, в разных проектах, для разных языков программирования. Когда формируется новая команда, ее членам, возможно, придется определять, обновлять, а затем адаптироваться к набору правил между ними, включая правила программирования. И да, на это нужно время.
Какие правила, какие руководящие принципы…?
Вместе мы можем определить наши собственные правила. Мы также можем сослаться на множество руководств по стилю, отредактированных опытными разработчиками из известных групп. Они могут быть одинаковыми, похожими или совершенно разными.
В любом случае, определение соглашений о кодировании для команды не всегда однозначно. Обсуждения необходимы для создания новых правил, выбора или уточнения существующих, а затем, наконец, для составления списка, который все согласны применять.
Что ж, все соглашаются подать заявку - мы думаем, что так и сделаем. В реальности:
Соглашения о кодировании иногда могут быть небольшим тормозом
Не все знают стиль программирования. Когда он определен и задокументирован, не все его проверяют. Тогда не каждый сможет применить все его правила в своем коде.
В большинстве случаев комментарии допустимы
Ах да. Кусок пирога. Я скажу тебе, когда это будет сделано.
Но
Иногда мы планируем собрание команды, потому что не можем договориться о едином названии.
Это так сбивает с толку. Думаю…".
"Как насчет…?
Что с этим не так? Имя мне нравится ».
«Что ж, я хорош с обоими».
"Ребята! Почему мы тратим так много времени на наименование только некоторых методов? »
Иногда мы не видим, сильно ли это помогает, но все равно вносим изменения.
«Хорошо, знаешь что, я сделаю это. Как ты думаешь, как тогда должно быть? »
Иногда мы ставим в приоритет цель спринта, накапливаем свой технический долг, думая, что скоро у нас будет достаточно времени, чтобы все решить.
Ваши комментарии интересны, но посмотрите, текущий код неплохой, правда? Что еще более важно, он работает, он прошел модульное тестирование. Давай, давайте объединим ветку, чтобы мы могли перейти к другой пользовательской истории! Нам следует сосредоточиться на нашей цели спринта, а затем мы сможем выполнить техническое задание, чтобы исправить их все. :)
Правила кодирования не должны быть обузой
Поскольку руководства по стилю стремятся сделать все аккуратно, они часто бывают очень длинными. Я уверен, что никто не может уважать руководство по стилю от А до Я. Тем не менее, соблюдать как можно больше правил - это хорошо.
Фактически, нам не обязательно помнить их все. Есть инструменты, которые нам очень помогли. Линтер кода анализирует исходный код на предмет возможных ошибок или нарушений правил. Программа форматирования кода даже исправляет некоторые проблемы со стилем. Мы можем настроить их и с помощью некоторых дополнительных скриптов заставить их запускаться автоматически при компиляции или непосредственно перед фиксацией. Чего они не могут сделать, так это соглашений об именах и передовых методов использования языка. Фрагмент, генератор или шаблон создают базовый общий код для классов, интерфейсов или блоков, все они могут быть хорошо отформатированы. Этими инструментами можно легко поделиться со всей командой, но наша работа по-прежнему заключается в том, чтобы завершить реализацию с использованием стиля кода команды.
Не следует так жадничать при определении правил именования. Мы должны иметь возможность пользоваться передовым опытом и интересными языковыми функциями.
Соглашения о кодировании не должны быть статичными, вместо этого они должны развиваться в течение жизненного цикла проекта и даже после него.
Несмотря на то, что соглашения о кодировании не влияют на количество ошибок или эффективность кода, на мой взгляд, их применение в проекте НЕ ДОЛЖНО, НЕ МОЖЕТ и НЕ ДОЛЖНО. Вместо этого, я полагаю, это должно быть приятным ОБЯЗАТЕЛЬНО, независимо от того, насколько велика команда.
Если вы только начали совместный проект и у вас нет руководства по стилю, сделайте его, задокументируйте и используйте. СРОЧНО.
Если проект начался какое-то время и каждый волен кодировать в своем собственном стиле, я бы сказал, что это огромная ошибка. Составьте собственное руководство по стилю, задокументируйте его и используйте. СРОЧНО. Также рекомендуется большой рефакторинг кода.
И, пожалуйста, не расстраивайтесь, когда ваш запрос на вытягивание / слияние будет отклонен из-за проблем с именованием! :]
Привет! Хлопайте в ладоши, если вам понравился мой пост, не так ли? Также не стесняйтесь делиться, оставлять комментарии и поправлять меня, если вы думаете, что я ошибаюсь в каком-либо пункте. Удачного кодирования!
