Formatowanie kodu ma znaczenie. Nawet wcięcie ma znaczenie . A spójność jest ważniejsza niż drobne ulepszenia. Ale projekty zwykle nie mają jasnego, kompletnego, weryfikowalnego i egzekwowanego przewodnika stylu od pierwszego dnia, a poważne ulepszenia mogą nadejść każdego dnia. Może to znajdziesz
SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;
można lepiej napisać, ponieważ / jest lepiej napisany niż
SELECT persons.id,
persons.name,
addresses.address
FROM persons
JOIN addresses ON persons.id = addresses.person_id;
podczas pracy nad dodaniem kolejnych kolumn do zapytania. Być może jest to najbardziej złożone ze wszystkich czterech zapytań w kodzie lub trywialne zapytanie spośród tysięcy. Bez względu na to, jak trudne jest przejście, zdecydujesz, że warto. Ale jak śledzić zmiany kodu w przypadku głównych zmian formatowania? Możesz po prostu poddać się i powiedzieć „to jest punkt, od którego zaczynamy od nowa”, lub możesz sformatować wszystkie zapytania w całej historii repozytorium.
Jeśli używasz rozproszonego systemu kontroli wersji, takiego jak Git, możesz powrócić do pierwszego zatwierdzenia i sformatować swoją drogę stamtąd do bieżącego stanu. Ale to dużo pracy i wszyscy inni musieliby wstrzymać pracę (lub przygotować się na matkę wszystkich fuzji) podczas jej trwania. Czy istnieje lepszy sposób na zmianę historii, który daje najlepsze wyniki:
- Ten sam styl we wszystkich zatwierdzeniach
- Minimalna praca scalania
?
Aby to wyjaśnić, nie chodzi o najlepsze praktyki przy rozpoczynaniu projektu, ale raczej o to , co należy zrobić, gdy duże refaktoryzacje zostały uznane za Dobrą Rzecz, ale nadal chcesz mieć możliwą do prześledzenia historię? Nigdy nie przepisywanie historii jest świetne, jeśli jest to jedyny sposób, aby upewnić się, że Twoje wersje zawsze działają tak samo, ale co z korzyściami programisty z czystego przepisywania? Zwłaszcza jeśli masz sposoby (testy, definicje składni lub identyczny plik binarny po kompilacji), aby upewnić się, że przepisana wersja działa dokładnie tak samo jak oryginał?
Odpowiedzi:
Przeprowadź formatowanie osobno. Spowoduje to minimalną ingerencję w historię i na pierwszy rzut oka powinieneś zobaczyć, które zmiany formatują, a które zmieniają kod. Może przechylać się
git blamei podobnie, ale jeśli wskazuje na zatwierdzenie tylko do formatowania, dość prosto można poszukać poprzedniej zmiany wcześniej.źródło
Nie przepisuj historii VCS: jest to sprzeczne z zasadami VCS.
Nie próbuj automatyzować naprawiania formatowania: leczy objawy, a nie prawdziwy problem (= programiści nie przestrzegają standardów kodowania).
Zdefiniuj standard kodowania i najlepsze praktyki formatowania we wspólnym dokumencie i poproś wszystkich programistów o zgodę.
Wspominasz o Git, co jest świetne, ponieważ jest rozpowszechniane. Dzięki DVCS bardzo łatwo jest egzekwować najlepsze praktyki poprzez przepływ pracy strażnika . Strażnicy odrzucają propozycje scalania (= ściągaj żądania w Git), które nie są zgodne ze wspólnymi wytycznymi. Mam na myśli odrzucenie pogrubionymi literami, w przeciwnym razie naruszający koder nie będzie zadawał sobie trudu przestrzegania zasad i nadal będzie powtarzał te same błędy.
Ta technika działa dla mnie dobrze. Koderzy chcą, aby ich praca została połączona, więc po kilku błędach na początku zaczynają przestrzegać zasad.
Jeśli chodzi o naprawianie istniejącej bazy kodu ... Zalecam robić to stopniowo, być może moduł po module lub jak to ma sens dla twojego projektu. Testuj dokładnie na każdym kroku. Może to zabrzmieć głupio, ale błędy zdarzają się nawet przy trywialnych zmianach, takich jak formatowanie, więc przygotuj się na drobne nierówności na drodze.
źródło
Odpowiedź na twoje rzeczywiste pytanie brzmi: „Ty nie”. Nie znam żadnego obecnego narzędzia SCM, które mogłoby śledzić zmiany w logice z kodu sformatowanego w jeden sposób, poprzez poważną zmianę formatowania i dalsze zmiany po sformatowaniu kodu w nowy sposób. I wiesz o tym, utrata historii na kodzie nie jest dobra.
W związku z tym zamierzam trochę zaprzeczyć twojemu pierwszemu zdaniu. Kod formatowania nie ma znaczenia , że dużo. Ładne jest miłe, ale nie po to tu jesteśmy. Rozumiem tak dobrze, jak każdy, kto zostaje wrzucony do czyjegoś piekielnie dziwnego kodu K&R z wcięciami dwóch spacji jest do bani (1), ale ... formatowanie nie jest przeszkodą w zrozumieniu, co się dzieje, chyba że jest to coś wyjątkowego patologiczny. W takim przypadku i tak będziesz mieć problemy ze zmianą kodu i nie powinieneś go niepokoić.
Dlatego nie warto wprowadzać zmian w ustalonym kodzie SZYBKO, aby go sformatować. Zmieniając nazwy zmiennych, rozkładając długie funkcje, wszystko to dobre refaktoryzacja, która zmienia treść, tak, ale nie TYLKO formatowanie.
1) - Kiedyś miałem przez pewien czas Przeglądarkę schowka Windows. Całość stanowiła jedna, 150k, moduł C. Znalazłem miejsce, w którym różni ludzie używali, jak sądzę, pięciu różnych stylów aparatu w odległości trzydziestu linii od siebie. Ale ta część rzeczy działała. Przez dziesięć lat nosiłem wydruk tego fragmentu kodu, ale nie naciągnąłem go, ponieważ ta historia się liczyła, a ten kod znajdował się w co najmniej trzech drzewach źródłowych (Windows 3.x, NT, przyszłość 95), które wszystkie żyły w różnych budynkach.
źródło
hg, odkryłem, że scalanie według części jest nieocenionym narzędziem w radzeniu sobie z trudnymi, dużymi scaleniami typu re-factor . Zazwyczaj to, co bym zrobił, to scalenie zatwierdzeń przed dużym ponownym współczynnikiem, następnie scalenie samego dużego ponownego współczynnika, a następnie w końcu scalenie zatwierdzeń od ponownego współczynnika. Każdy z tych trzech scala na własną rękę są znacznie łatwiejsze niż próbuje rozwikłać ten bałagan, który wynika z prowadzenia wszystkich scala w jednym zamachem.Zmiany formatowania są zmiany w kodzie; traktuj je jak każdą inną zmianę w kodzie. Każdy, kto pracował nad znaczącym projektem, prawdopodobnie zobaczy błędy i inne problemy, które powstały, gdy ktoś postanowił „po prostu” sformatować jakiś kod.
Dlaczego musisz ponownie sformatować wszystko jednocześnie? Zwłaszcza jeśli ponowne formatowanie nie zmienia znaczenia kodu, powinieneś być w stanie ponownie formatować pliki indywidualnie i rejestrować je w miarę postępów. Lepiej, zachęć wszystkich członków zespołu do uzgodnienia stylu (w przeciwnym razie i tak nie ma sensu formatowania) i niech wszyscy zajmą się ponownym formatowaniem w trakcie swojej drugiej pracy. Po chwili ominiesz większość kodu, nie zakłócając reszty projektu.
źródło
Istnieją realne dwa podejścia, które widziałem w tym celu.
1. Sformatuj kod po zakończeniu przechwytywania
Podczas gdy początkowo podnoszenie włosów ma na celu zmianę kodu po jego przesłaniu, jeśli twoja procedura formatowania (np. Astyle ) nie zaszkodzi kodowi, jest to bezpieczna operacja. Z czasem cały zespół zauważy, że cały kod ostatecznie wygląda tak samo. Oczywiście posiadanie kompleksowych testów jednostkowych / automatycznych zapewni, że nic się nie zepsuje.
2. Jednorazowe formatowanie całego kodu
Z mojego doświadczenia jest to bardziej niebezpieczne i utrudnia śledzenie problemów w Wielkim Wybuchu, ale jest to możliwe. Niezbędne jest przeprowadzenie wszystkich testów później. W przypadku stylu kodowania większość różnic dotyczy używania białych znaków - wcięć lub znaków nowej linii. Przyzwoite narzędzie do scalania powinno mieć możliwość ignorowania wszystkich różnic między białymi spacjami, więc pomoże to w scalaniu.
źródło