Этикет с открытым исходным кодом

Я начал работать над своим первым проектом с открытым исходным кодом на Codeplex и натолкнулся на какой-то ужасный код. (Я узнал, что в C # все еще есть оператор "goto") Я начал добавлять функции, которые хотел "владелец", и после изучения базы кода и просмотра, что это за беспорядок (например, с помощью "goto"), я хотел его убрать немного. Но я немного обеспокоен, и именно поэтому я обращаюсь ко всем вам: это правильный этикет для меня, чтобы «исправить» «плохой код», или я должен оставить его и работать над новыми функциями? Как я уже говорил ранее, я новичок на всей сцене OSS и работаю в команде в целом, поэтому я хотел бы не испортить это.

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

Цель открытого исходного кода - привлечь внимание к проекту и улучшить его. Это включает в себя улучшение кода. Тем не менее, это хорошая форма для рекламы в списке, что вы собираетесь делать. Вы можете получить некоторый толчок назад, или вы можете получить кучу +1. Эти gotoзаявления просто могут быть там, потому что первоначальный автор не мог придумать лучшего способа выполнить работу. Если вы получаете толчок назад, хорошо войти в диалог, чтобы выяснить, откуда исходит давление. Попытайтесь не позволить этому стать личным, и попытаться решить проблемы.

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

Помните, что в открытом исходном коде сообщество важнее, чем код. Если нет сообщества (как пользователей, так и разработчиков), то проекта нет.

Люди, которые ревностно защищают свой код, как правило, не публикуют его для тщательного изучения мира, и если они это сделают, сообщество вокруг этого не продлится очень долго. Будьте тактичны, но не беспокойтесь, что вы обидите чувства.

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

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

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

Говоря из опыта ...

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

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

Если вы работаете с кем-то, кто «хорош» (как я), он немедленно отклонит патч. Главным образом потому, что, когда вы вносите свой вклад в проект с открытым исходным кодом, вы должны разбить свои исправления на куски кусочков, которые решают одну проблему. «Удалено все gotos» не является хорошим примером атомарного коммита. Даже если сначала разбить его на более мелкие, хорошо документированные коммиты, он все равно может быть отклонен.

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

Рефакторинг кода и добавление функциональности (или удаление устаревшего кода) обычно имеет приоритет перед «очисткой» кода.

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

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

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

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

Прежде чем тратить много времени, пытаясь «исправить несправедливость ошибок другого стиля кодирования», спросите себя:

Являются ли предлагаемые вами изменения основанными на добавлении ценности проекту или они основаны на вашей собственной внутренней стилистической религии.

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

В мире Open Source стиль не так важен. Функция есть .

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

Качество> Этикет

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

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

Общение с оригинальным автором также хорошая идея.

В этом нет ничего плохого goto. Посмотрите на ассемблерный код - множество gotos (прыжков и веток) повсюду.

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

Обратите внимание, что это было 50 лет назад, когда разработка программного обеспечения еще даже не называлась, и большинство языков программирования были, по сути, абстракциями базовой машины, так что машинный язык содержал goto, как и они. Вы можете попробовать программировать некоторые из них на Microsoft Basic (оригинал, на Apple] [или Commodore 64), чтобы понять, каково было это мышление.

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

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