Как насчет всех этих правил кодирования?

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

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

Вовлеките их в решение проблемы, а не в борьбу с правилами. Я лично предпочитаю идею «руководств по стилю», «стандартов кодирования» или чего-то подобного, в надежде, что это предотвратит реакцию «колено = плохо».

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

Иногда давление со стороны сверстников является лучшим решением для этого.

В моей работе мы используем все три следующих решения:

1) Примите средство проверки стиля кода, такое как отличный Checkstyle (для Java) или StyleCop (для C #). Это легко настраиваемые инструменты, которые могут автоматически выделять стиль кодирования / отклонения правил. Это дает всем нейтральную третью сторону, чтобы определить, что является приемлемым.

2) Примите автоматически переформатированный шаблон кода (вот пример с использованием Eclipse) (и другой для Visual Studio), который автоматически отформатирует ваш код при сохранении. Это отлично подходит для того, чтобы позволить кому-то писать код так, как он хочет, но форматировать весь код при сохранении / фиксации одинаково. Мне очень нравится этот, и наш код никогда не был более последовательным.

3) Кодекс отзывов. Надеюсь, вы все равно это делаете, но одна вещь, на которую следует обратить внимание, это то, где правила / стили кодирования нарушают соглашение.

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

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

Являются ли они «жесткими», не используя скобки, или это «жесткая» просьба?

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

OO 101 : «Рефакторинг, когда продукт делает то, что ему нужно». Не раньше, чем.

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

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

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

Я думаю, что вы говорите о проблемах самых разных уровней:

как сделать тех, кто не любит использовать скобки в операторах if,

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

или используйте одну и ту же строку соединений везде в коде,

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

или что угодно, использовать правила кодирования, не заставляя их противостоять идее?

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

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

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

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

Везде одинаковая строка подключения? Решение этой проблемы заключается в рефакторинге, пока вы не удалите все дубликаты. Копировщики должны пойти в тюрьму программиста. (Не смейся! Стив Баллмер - начальник.)

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

Как бы я решил это:

1. Настаивайте на том, чтобы у команды был общий стандарт кодирования. Это может быть 5 строк, но все они должны согласиться.
2. Каждый раз, когда вы замечаете какой-либо аргумент, настаивайте, чтобы они уладили его и включили в стандарт кодирования. Если вы замечаете, что люди переформатируют вещи назад и вперед, рассматривайте это как аргумент.
3. Всякий раз, когда согласовывается стандартный элемент, посмотрите, есть ли инструмент, который очистит всю базу кода сразу.
4. Каждые пару месяцев проходите через стандарт кодирования и смотрите, какие из них все еще актуальны и актуальны. Стандарт только документирует, что люди делают. И нет смысла хранить в стандарте элементы, которые стали очевидными.

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