Эволюция в стандартах кодирования, как вы справляетесь с ними?

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

Допустим, ваша кодовая база содержит около 500 000 строк кода. Вы все еще хотите изменить весь существующий код? Или вы позволите только новому коду соответствовать новому стандарту? В основном потерять последовательность?

Как вы справляетесь с эволюцией стандартов кодирования в вашем проекте?

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

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

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

Что мы делаем, так это эволюция (не революция) для базы кода, мы будем использовать обновленный стандарт, когда;

• новый код написан
• код рефакторинг
• исправлены ошибки
• новые части добавляются в существующий класс

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

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

Тем не менее, есть два случая для изменений в стандарте кодирования:

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

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

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

Лично я бы предпочел оставить старые коды такими, какие они есть, и следовать новым стандартам из того, что вы делаете новыми. В частности, я не буду использовать двойные стандарты в old.c. Но если я собираюсь создать new.c, он может использовать более новые, усовершенствованные синтаксисы :)