gulnyr

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

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

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

Сконцентрируйте все свои усилия только на том, что действительно необходимо и что позволит в наибольшей мере улучшить выпускаемый вашей командой код. Не занимайтесь самостоятельной разработкой стандартов для Java, C, C++, если вы пользуетесь в своей работе только C или т.п. язык программирования.

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

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

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

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

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

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