Как вы работаете с программистом с совершенно другим стилем кодирования?

Ответ 1

Выберите один и идите с ним.

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

• поддержка инструмента для автоматического форматирования (не знаю, что я знаю, что Eclipse и Visual Studio могут делать это с помощью файла настроек)
• соответствие стандарту общепромышленного стандарта (Sun опубликовала стандартные соглашения для Java, возможно, на вашем языке есть эквивалент?)
• соответствие или стоимость модификации ранее существовавшего источника (если у вас есть миллион строк в одном стиле, насколько сложно будет обновить этот код до нового стиля?)
• ... любой важный фактор, который любой из вас считает важным (это может включать стоимость, чтобы ознакомиться с новым стилем)

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

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

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

Ответ 2

Мы соглашаемся на стандартный стиль кодирования и применяем его в виде файлов настроек Visual Studio.

Ответ 3

Это проблема человеческого общения. Просто поговорите друг с другом. Не через код, лично.

Ответ 4

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

Ответ 5

• с использованием IDE в сочетании с плагинами для проверки стиля (в случае Java - Checkstyle, PMD) руководитель группы или даже руководитель проекта (если технический человек) может принуждать правила стиля кода для всей команды.

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

• обсудите стили кода и компромисс, затем примените возможности IDE, упомянутые в первой точке.

Ответ 6

Когда вы говорите "стиль кодирования", вы имеете в виду форматирование или разницу в структуре структуры кода?

Что касается стиля кодирования, команда должна, вероятно, иметь форматирование стиля и применять какой-то формат перед фиксацией. таким образом, слияния не приведут к слиянию слияния.

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

Ответ 7

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

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

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

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

Ответ 8

Ваш стиль не является нормой. Его стиль не является нормой. Нормой является стиль кодирования, выбранный проектом, или, иногда, вся организация (и это должно быть документировано где-то), и вы оба должны соблюдать ее. Инструменты, такие как Checkstyle (с Java), могут использоваться для обеспечения соответствия. Если вы используете такой инструмент, распространите его файл конфигурации. Также распространяйте файлы для конфигурации форматирования IDE.

Многие проекты с открытым исходным кодом (или корпоративные) действительно используют эти принципы (см., например, XWiki Стиль Java-кода, Maven Code Style и условные обозначения кода или Руководство по языку стилей для разработчиков Apache Developers '). Это работает для разработчиков, распространяемых по всему миру, не говорите мне, что это не может работать для разработчиков в одной комнате.

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

Ответ 9

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

У вас есть 4 варианта, - вы либо конвертируете их - вы преобразуетесь - вы предлагаете стандарт компании. - вы живете с ним.

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

personName vs sPersonName vs strPersonName < - который вы бы выбрали?

если вы имеете в виду форматирование, ctrl-a, k f < - форматирует ваш код в VS:)

Ответ 10

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

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

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

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

Ответ 11

Это зависит.

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

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

Ответ 12

Вам придется изобретать какой-то стиль, подходящий для вас обоих и придерживающийся его. И если общение является проблемой, просто придерживайтесь идеи: "Когда я пишу сам, я не прикасаюсь к другому коду"