Как убедить руководство в том, что переформатирование всей базы кода Java безопасно

Question

Как можно доказать руководству, что пакетное переформатирование всех файлов .java в большой кодовой базе (для размещения кода в соответствии со стандартами кодирования компании) безопасно и не повлияет на функциональность.

Ответы должны были бы удовлетворить как нетехнических, так и технических.

Редактировать: 2010-03-12 Разъяснение технического среди вас; reformat = изменения только для пробелов - нет «организации импорта» или «переупорядочения переменных-членов, методов и т. д.»

Редактировать: 2010-03-12 Спасибо за многочисленные ответы. Я удивлен, что так много читателей проголосовали за ответ mrjoltcola, поскольку это просто утверждение о том, что он параноик, и ни в коем случае не предлагает ответ на мой вопрос. Более того, есть даже комментарий того же автора, повторяющий вопрос. WizzardOfOdds поддержал эту точку зрения (но вы, возможно, не читали все комментарии, чтобы увидеть ее). -jtsampson

Редактировать: 2010-03-12 Я скоро опубликую свой собственный ответ, хотя ответ Джона Скита был прав на деньги с предложением MD5 (примечание -g: ни один, чтобы отключить отладку). Хотя это только технические аспекты. -jtsampson

2010-03-15 Я добавил свой ответ ниже. В ответ на то, что означает «безопасный», я имел в виду, что функциональность кода Java не пострадает. Простое исследование компилятора Java показывает, что это так (с несколькими оговорками). Предостережения Thos были «только пустым пространством» и были отмечены несколькими плакатами. Однако это не то, что вы хотите попытаться объяснить BizOps. Моя цель состояла в том, чтобы найти ответы типа «как оправдать это», и я получил несколько отличных ответов.

Несколько человек упомянули контроль над источниками и «веселье», которое сопровождает его. Я специально не упомянул это, поскольку эта ситуация уже хорошо понята (в моем контексте). Остерегайтесь эффекта «АЗС». Смотрите мой ответ ниже.

Answer 1

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

Answer 2

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

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

• Все разработчики имеют одинаковые настройки форматирования;
• Форматирование исходного кода проверяется при регистрации хуком в вашем SCM.

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

Answer 3

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

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

Последнее замечание: если вам нужно убедить в этом свое руководство, может, вам стоит поискать способ работать с более умными людьми?

Answer 4

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

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