Форматування коду має значення. Навіть відступ має значення . А послідовність важливіша, ніж незначні покращення. Але проекти, як правило, не мають чіткого, повного, перевіреного та застосовуваного посібника щодо стилю з 1-го дня, і серйозні вдосконалення можуть надійти будь-якого дня. Можливо, ви знайдете це
SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;
може бути краще написано так, як / краще написано ніж
SELECT persons.id,
persons.name,
addresses.address
FROM persons
JOIN addresses ON persons.id = addresses.person_id;
під час роботи над додаванням більшої кількості стовпців до запиту. Можливо, це найскладніший з усіх чотирьох запитів у вашому коді, або тривіальний запит серед тисяч. Як би важкий не був перехід, ви вирішили, що він того вартий. Але як відстежувати зміни коду за основними змінами форматування? Ви можете просто відмовитись і сказати, "це ми починаємо знову" або ви можете переформатувати всі запити у всій історії сховищ.
Якщо ви використовуєте розподілену систему керування версіями, як-от Git, ви можете повернутися до першої фіксованої версії та переформатувати свій шлях звідти в поточний стан. Але це велика робота, і всі інші повинні були б призупинити роботу (або бути готовою до матері всіх злиття), поки вона триває. Чи є кращий спосіб змінити історію, який дає найкращі результати:
- Один стиль у всіх комітах
- Мінімальна робота злиття
?
Для уточнення, мова йде не про найкращі практики при запуску проекту, а про те, що слід робити, коли великий рефакторинг був визнаний хорошою річчю ™, але ви все ще хочете простежити історію? Ніколи не переписуйте історію чудово, якщо це єдиний спосіб забезпечити, щоб ваші версії завжди працювали однаково, але як щодо переваг розробника від чистого переписування? Особливо, якщо у вас є способи (тести, визначення синтаксису або ідентичний бінарний файл після компіляції), щоб переконатися, що переписана версія працює точно так само, як оригінал?