Перевод статьи «How to choose the best code conventions for you and your team».
– Слушай, эти приватные переменные должны идти после публичных!
– Ни в коем случае! Публичные переменные идут перед приватными!
– Давай спросим Деб, пускай она решает.
– Погодите, а почему эти константы не в camel-case?
Поднимите руки те, кому случалось побывать в подобных ситуациях. ОК, на самом деле можно не поднимать, но что-то мне подсказывает, что многие из вас принимали участие в подобных сценариях.
Поскольку я занимаюсь разработкой последние десять лет, я припоминаю свое участие во многих (возможно, слишком многих) дискуссиях по поводу стандартов оформления кода (code conventions). Эти обсуждения, как бы полезны они ни были, порой перерастают в бесконечные философствования. А затем они начинают захватывать все больше тем, от отступов до структуры папок.
Это может быть болезненно.
Так как же решить, какой стандарт самый лучший? И существует ли он вообще, этот «лучший» стандарт? Я расскажу, как выбраться из бесконечного цикла дискуссий и прекратить философские споры раз и навсегда.
Зачем вообще нужен стандарт оформления кода?
Прежде чем определить, какой стандарт будет наилучшим и существует ли он вообще, нужно разобраться, зачем нам вообще какой бы то ни было стандарт.
Для применения стандартов есть множество причин, я остановлюсь на самой важной: читаемости кода.
Что, если я вдруг решу писать только капсом? ВОТ ТАКОЙ ТЕКСТ БУДЕТ ВЫГЛЯДЕТЬ НЕСКОЛЬКО СТРАННО. Вы это непременно заметите, а ваш мозг начнет обдумывать, что изменилось.
Примените этот простой пример к именам переменных и отступам. Если каждый раз, когда вы возвращаетесь к коду, он выглядит иначе, вы каждый раз будете заново в него вникать. Но если код написан в рамках каких-то заранее определенных правил, его будет легче понять, а значит, он будет более читаемым, даже если был написан много месяцев назад.
Все становится гораздо хуже, когда над кодом работает команда разработчиков, где каждый пишет собственный код, руководствуясь только личными предпочтениями, собственными наборами правил. Чтобы разобраться в коде друг друга, у вас уйдет… ну… вы поняли смысл.
Для того чтобы эффективно и качественно сотрудничать с другими разработчиками, вам нужен общийстандарт оформления кода.
«Программы должны писаться для того, чтобы их читали люди, а выполнимость этих программ машинами это побочный эффект», – Гарольд Абельсон.
Как выбрать лучший стандарт
Возможно, вы только учитесь писать код, а возможно, являетесь частью звездной команды разработчиков. А может, вы только что стали техническим директором. И вот перед вами встал вопрос выбора тех общих правил, которыми вы и ваша команда будете руководствоваться при написании кода.
При выборе лучшего для себя стандарта я рекомендую делать следующее:
- Поискать вдохновение в командах, которыми вы восхищаетесь. Опыт имеет самый высокий приоритет, а некоторые из крупнейших и умнейших компаний публикуют свои руководства по написанию кода. Например, компания Airbnb опубликовала свои стандарты оформления кода для JavaScript и Ruby, а Google – для Java и Python. Нравятся вам эти компании или нет, не слишком важно. Просто если суммировать годы опыта разработчиков в их командах, мы получим какое-то огромное число. Попробуйте применить стандарты подобных компаний в своей команде.
- Соберите мнение коллег. Нам, разработчикам, повезло быть частью динамичного сообщества. По факту, наше сообщество это одно из самых больших преимуществ разработки как сферы деятельности вообще. Вы всегда можете найти группы знающих людей на различных платформах для сотрудничества, таких как Slack, Spectrum, Discord. Найти – и опубликовать вопрос относительно стандартов оформления кода. Вы немедленно получите мнение множества разработчиков со всего мира.
- Игнорируйте примеры кода. Да, просто игнорируйте их. Я постоянно натыкаюсь на код, который скопировали из ответа на Stackoverflow или откуда-то еще. Люди забывают, что примеры кода, которые они только что скопировали, были, вероятно, написаны в ответ на конкретный технический вопрос или для объяснения работы какой-то библиотеки. В большинстве случаев автор кода в примере не собирался придерживаться каких-то стандартов оформления кода или просто не имел на это времени.
Эти советы помогут вам начать процесс выбора. Найденные таким образом стандарты могут лечь в основу того, что вы предложите своей команде.
А теперь немного философии.
Существует ли «лучший» стандарт оформления кода?
Это зависит от того, что вы вкладываете в понятие «лучший». Если какой-то стандарт используется в Airbnb или Google, или 10 разных технических директоров сказали вам, что их собственный стандарт лучший, означает ли это, что данный стандарт является лучшим для вас?
Более того, стандарты оформления кода вещь переменчивая. Можно ли вообще называть «лучшим» то, что меняется со временем?
Когда я пришел в Lemonade в качестве единственного фронтенд-разработчика, мне было сложно читать код, написанный моим предшественником. Возможно, он считал такой стиль самым лучшим, но я – нет. Поэтому я переписывал каждый кусочек кода, с которым работал, чтобы он соответствовал моему собственному стандарту. Со временем к команде присоединялось все больше разработчиков, и наши стандарты менялись.
Каждый приходящий разработчик имел свой собственный бэкграунд, со своими стандартами и соглашениями. Чтобы формализовать наши стандарты, мы взяли за точку отсчета стандарт оформления кода на JavaScript от Airbnb. Мы пересмотрели изложенные там правила и изменили или удалили то, с чем были не согласны, а то, что нам понравилось, применили у себя. Мы даже принимали стандарты, которые приносили в команду наши коллеги-разработчики, и интегрировали их в наш главный стандарт.
Процесс оценки каждого стандарта и определения, стоит ли его принять, не только помог улучшить читаемость нашего кода, но и содействовал сплоченности команды.
Итак, горькая правда: нет никакого универсального определения того, какойстандарт оформления кода считать лучшим, просто потому что лучшего стандарта не существует.
Вопреки тому, чему учат в школе, не всегда есть правильный ответ для любого вопроса. В данном случае таких ответов может быть много.
У разработчиков есть множество способов реализовать разные или даже одинаковые вещи. Некоторые предпочитают, чтобы имена всех членов класса начинались с суффикса «m_». Кому-то нравятся отступы в два пробела, а кому-то табы. Кто-то скажет, что неправильно использовать слово Utils в качестве имени класса. Обсуждать это можно бесконечно, и у каждой точки зрения могут быть хорошие основания.
В конечном итоге все сводится к тому, какой стандарт улучшит читаемость вашего кода. Какой стандарт позволит вашей команде лучше коммуницировать, а также быстрее и эффективнее продвигаться вперед.
Помните о том, что стандарты оформления кода это просто рекомендации. Да, выбрав, для себя стандарт, нужно его придерживаться. Но эти руководства по стилю не высечены в камне и могут меняться. Позвольте себе поэкспериментировать с разными вариантами, пока не найдете тот, который лучше всего подойдет вам и вашей команде.
Итак, какой стандарт оформления кода можно считать лучшим? Ответ прост: ваш!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]