Недавно я натолкнулся на ряд проектов с открытым исходным кодом Ruby (или большинство из них был Ruby) на GitHub, которые при проверке с помощью инструмента анализа кода, такого как Rubocop , создают много нарушений .

Теперь большинство этих нарушений включают использование двойных кавычек вместо одинарных кавычек (если не интерполяция), не следование правилу 2 пробелов на уровень, превышение правила длины строки из 80 символов или использование {и }для многострочных блоков.

[The] Руководство по стилю Ruby рекомендует лучшие практики, чтобы реальные программисты Ruby могли писать код, который может поддерживаться другими реальными программистами Ruby. ~ Источник: Руководство по стилю Ruby

Хотя они небольшие и их легко исправить, уместно ли менять стиль кодирования проекта с открытым исходным кодом, исправляя нарушения и делая запрос на извлечение? Я признаю , что некоторые проекты, как Rails, не принимают косметические изменения и некоторые из них просто слишком велики , чтобы «исправить» все сразу (Rails, например , генерирует более 80 тысяч преступлений , когда Rubocop управляют - независимо от того , у них есть свой собственный небольшой набор кодирования условности, которым необходимо следовать при содействии). В конце концов, есть руководство по стилю Ruby вместе с такими инструментами, как Rubocop.

Люди ценят последовательность, поэтому внесение подобных изменений - полезная вещь для сообщества Ruby в целом, верно?

[Автор (ы) Ruby Style Guide] не придумали все правила из ниоткуда - в основном они основаны на моей обширной карьере профессионального инженера-программиста, отзывах и предложениях членов сообщества Ruby и различных высоко ценимые ресурсы программирования Ruby, такие как "Программирование на Ruby 1.9" и "Язык программирования Ruby". ~ Источник: Ruby Style Guide

Разве не следование соглашениям и рекомендациям по стилю кодирования сообщества в основном поощряет плохие практики?

Спросите у сопровождающих.

Стиль кодирования является довольно субъективным обсуждением, а правила, такие как максимальная длина строки в 80 символов, довольно субъективны - хотя общее согласие должно заключаться в том, что более короткие строки лучше читать, 80 может быть слишком ограничительным для некоторых с сегодняшними размерами экрана и IDE.

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

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

Вы, кажется, мотивированы в значительной степени уважением к авторитету инструмента rubocop и Руководству по стилю Ruby, которое сопровождающие могут не поделиться. У них уже есть свой собственный стиль, и он к нему привык, поэтому любое изменение повлияет на всех, кто работает над проектом, и это большая работа, особенно если проект большой.

Рассмотрим мотивы сопровождающих. Они (вероятно) хотят, чтобы к ним присоединились новые люди, предоставляя исправления, отчеты об ошибках, рабочий код и хорошо написанную документацию. Если вы приходите и говорите: «У вас есть преступления в рубокопе», они не будут думать «О, хорошо, кто-то новенький, чтобы помочь разделить нагрузку», они будут думать: «Кто этот парень? Почему он говорит нам? что делать?".

Проекты с открытым исходным кодом, как правило, являются меритократий: вы получаете уважение в зависимости от качества вашей работы. Если вы приходите и делаете отличные вещи, а затем поднимаете свои проблемы со стилем, они с большей вероятностью прислушаются, хотя все равно могут сказать «нет». Существует открытый исходный текст, в котором говорится: «Говори дешево, покажи мне код».

Прагматизм над Догмой, всегда. Руководства по стилю кодирования - это особенно коварная форма зла, которая отвлекает внимание от архитектурных забот к легкомысленной чепухе, такой как одинарные / двойные кавычки. Спросите себя: действительно ли это имеет значение?

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

Должны ли они просто быть проигнорированы тогда? Нет, есть смысл использовать инструменты, чтобы получить общее представление о том, на что нужно смотреть, но не более.

Удивительно, как часто юные типы путают мнение с фактом.

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

Если проект не настолько важен для вас, чтобы поддерживать свою собственную ветку, то в первую очередь его не стоит очищать.

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

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

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

Разветвление, слияние и фиксация кажутся единственным решением.

Взято с самого сайта Rubocop (выделено мое):

Одна вещь всегда беспокоила меня как разработчика Ruby - разработчики Python имеют отличный справочник по стилю программирования (PEP-8), и у нас никогда не было официального руководства , документирующего стиль кодирования Ruby и лучшие практики.

Пожалуйста пойми:

Официального руководства по стилям Ruby не существует

Я не говорю, что руководства по стилю плохие. Но не только нет официального руководства, но и руководство по стилю - это выбор, который делается на личном уровне, уровне проекта, команды, компании. Руководства по стилю, если использовать термин психологии, являются «внутригрупповой социальной нормой».

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

Вы не можете просто предложить руководство по стилю?

На самом деле, кажется, это то, что вы хотите сделать: вы верите в ценность руководств по стилю, вы очень цените последовательность и хотите благовествовать за приверженность унифицированным руководствам по стилю.

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

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

Чтобы предложить альтернативное мнение здесь, во многих случаях такое изменение будет приветствоваться. Проекты с открытым исходным кодом, как правило, имеют много авторов. Часто нет «стиля кодирования»; стиль - это то, что использовал тот, кто написал этот код. Если один файл был написан другим человеком, чем другой, стиль может также отличаться. Даже в проектах, где существует согласованный стиль, если они не проверяют этот стиль регулярно, он часто не используется.

Типичным примером этого в моем опыте является случай, когда кто-то вносит некоторый код через запрос на извлечение, который имеет относительно низкое качество по стилю. Тем не менее, код может работать. У разных людей разные взгляды на это. Некоторые люди откажутся объединить запрос на удаление, если стиль не будет хорошим. Некоторым людям все равно, пока работает код. Некоторые люди предпочитают иметь хороший стиль, но они не хотят отпугивать участников с помощью множества комментариев «исправить пробел здесь» (лично я всегда чувствую себя немного виноватым, делая эти комментарии, хотя я знаю, что они к лучшему хорошо из кодовой базы, потому что это действительно может отпугнуть участника).

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

Вы должны знать о некоторых вещах, хотя:

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

• Это огромная проблема, связанная с велосипедами . Все и их брат имеют мнение об этих вещах. Из-за этого может быть сложно получить такой объединенный запрос.

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

Я бы придерживался подхода «сначала спроси». Если они открыты для этого, и вы готовы придерживаться запроса на удаление до завершения, тогда сделайте это.

Раньше у меня было хорошее руководство по стилю, но, учитывая положение дел в Ruby, «я пошел дальше».

По сути, я живу с тем, с чем работаю, и в остальном следую общим правилам, которые я выучил на ряде работ.

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

Примеры каждого стиля (на мой взгляд):

Общепринятый для Ruby:

• пробелы не табуляции
• два пробела
• method_names_use_underscores
• Константы начинаются с заглавных букв.

Общепринятый:

• Не используйте скобки, если не нужно
• Используйте { }для блоков с одной строкой и do endдля блоков с несколькими строками.
• CONSTANTS_ARE_IN_ALL_CAPS
• Используйте предикативные операторы ( cond ? true : false), if thenесли выражение помещается в 1 строку.

Личные предпочтения:

• Длина строки из 120 символов
• whenОператоры case имеют отступ 2 от оператора case.
• Используйте одинарные кавычки, если не нужны двойные.

Нет соглашения:

• Заявления по делу
• Длина линии

Лучшие практики:

• маленькие методы, <= 5 строк, если это возможно.
• маленькие классы, <= 100 строк, если это возможно.
• Избегайте констант
• Код имеет тесты

Наконец, как другие подробно описали, вы должны сначала спросить. В конце дня ключом к стилю является общение между разработчиками и чувствительность к другим. Например, если я хочу изменить стиль в проекте с открытым исходным кодом, я часто делаю предварительный запрос для одной или двух реальных функций или исправлений ошибок. После того , как сопровождающий меня знает и видит , что я способствовал, то я мог бы предложить изменения стиля. Я только предлагаю их хотя. Например, «Делая другую функцию в проекте x, я заметил, что у вас есть 4 пробела в паре файлов, и мне было интересно, смогу ли я изменить их на 2?»

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

Короче нет!

Конечно, я предполагаю, что это просто вопрос стиля, а не настоящие ошибки - запросы на получение последнего всегда будут разумными (IMO). Я также предполагаю, что вы незнакомы с проектом и не в контакте с людьми, которые уже поддерживают это.

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

Это немного изменится, если вы захотите внести свой вклад в проект другими способами, кроме как делать «исправления» стиля. Я бы сказал, что если вы хотите открыть диалог с сопровождающими о том, как вы хотели бы работать над проектом, но найти нестандартный стиль сложно, то это нормально. Но я бы не стал слепо создавать запросы на извлечение для нескольких проектов, содержащих только изменения стиля!

ЛЮБОЕ изменение может привести к ошибкам, даже изменяя типографское форматирование кода.
Поэтому никакие изменения не должны выполняться в коде, если нет действительного бизнес-кейса, и «но код выглядит не очень хорошо» или «код не соответствует стандартам кодирования» не является действительным бизнес-кейсом. Риск просто слишком велик.
Теперь, если вы все равно вносите серьезные изменения в исходный файл, приведение всего файла в соответствие со стандартами может быть приемлемым, но, скорее всего, вы будете вносить небольшие изменения, и в этом случае почти всегда предпочтительнее сохранять свои собственные изменения в соответствие существующему коду, даже если этот существующий код не соответствует стандартам кодирования.
Черт возьми, код вполне может быть результатом генератора кода и время от времени восстанавливаться. Генераторы кода печально известны производством уродливого кода ...

У меня есть пара умеренно успешных проектов .NET, и у меня было несколько PR от людей, которые, кажется, прошли через код с помощью ReSharper и StyleCop и «исправили» кучу вещей. Я не принимаю эти PR по нескольким причинам:

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

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

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

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