Co zrobić, jeśli współpracownik edytuje kod, aby zmienić jego wygląd?

16

Co powinieneś zrobić, jeśli współpracownik edytuje Twój kod?

Bez celu dodawania funkcjonalności lub naprawiania błędów, wystarczy zmienić wygląd ...

Tamara Wijsman
źródło
9
Zakładam, że masz z tym problem. Jeśli tak, to dlaczego? Czy to pogarsza kod ?
Zaz
3
@Josh: Tak, w rzeczywistości pogarsza kod, ponieważ jest trudniejszy do utrzymania przez innego programistę niż facet, który go napisał.
Robert Koritnik
4
daj mu więcej pracy
Oscar Cabrero
4
@Robert - Myślę, że tęsknisz za punktem Josha. Zmiana wyglądu kodu może sprawić, że będzie on obiektywnie łatwiejszy w utrzymaniu ... zwłaszcza, jeśli na początku był źle sformatowany.
Stephen C
4
Czy to naprawdę twój kod, czy należy do zespołu?
Eric King,

Odpowiedzi:

28

Porozmawiaj z nimi na ten temat. Przejdź do rozmowy z postawą: „Nie robią tego, aby mnie drażnić lub dlatego, że mają jakąś formę zaburzenia obsesyjno-kompulsywnego; starają się ulepszyć mój kod”.

Ponieważ możesz się mylić. To może być subtelna poprawka i po prostu jej nie zauważyłeś.

Lub może być tak, że istnieje standard kodowania, o którym nie wiesz, że naruszasz, a oni po prostu go poprawiają.

Lub może być tak, że próbują cię zirytować lub mają jakąś formę zaburzenia obsesyjno-kompulsyjnego. Jeśli tak jest, poproś ich, aby przestali, a jeśli to nie zadziała, skontaktuj się z szefem.

Ale nigdy się nie dowiesz, chyba że zapytasz.

BlairHippo
źródło
17
Warto zauważyć, że wiele IDE ma funkcje automatycznego formatowania. Używam ich cały czas, nie myśląc o tym. Niektóre sformatują nawet wszystkie pliki w projekcie lub wszystkie otwarte pliki, w zależności od konfiguracji. Przypadkowe automatyczne formatowanie może być łatwe.
Matt Olenik,
@Matt: Doskonały punkt.
BlairHippo,
1
„Nie robią tego… ponieważ mają jakąś formę zaburzenia obsesyjno-kompulsyjnego;” Mówiąc przede wszystkim o sobie, nie zawsze tak jest! Jeśli chodzi o kod, jestem dwiema rzeczami: perfekcjonistą i zgrabnym dziwakiem. Mimo to na ogół staram się unikać stosowania tej mentalności w pracy moich kolegów.
Nathan Taylor
5
Och, nie mówię, że kolega Toma NIE JEST schludnym dziwolągiem z zaburzeniami obsesyjno-kompulsyjnymi ze słabym wyczuciem granic. Mówię tylko, że wchodzę w rozmowę z nastawieniem: „Co do diabła jest z tobą nie tak ?!” nie jest dobrym sposobem na produktywną rozmowę. :-)
BlairHippo
1
@Chris nie musisz się martwić o uzasadnienie, zawsze Ctrl + K + D!
Nathan Taylor
16

Nie jestem tak żonaty, jak mój kod go niepokoi. :) Staram się uczyć od zmian. Czy mój współpracownik dostosował nazwy zmiennych? Napisz bardziej wydajną pętlę? Czy kod jest bardziej czytelny?

Jeśli nie widzę, jak zmiany poprawiły to, co już było, zwykle pytam współpracownika, który je wprowadził, jaka była ich motywacja. Możliwe, że korzyść nie jest dla mnie oczywista. A jeśli mam rację, a oni się mylą, to może wyjaśnię, dlaczego napisałem to tak, jak to zrobiłem.

Jeśli wszystko inne zawiedzie, cofnij odprawę. ;)

Edycja: Wszystkie zakłady są wyłączone, jeśli chęć wprowadzenia kosmetycznych zmian wprowadzi błąd.

Adam Lear
źródło
9

IMO ty i twój zespół i tak powinniście stosować standard kodowania. W takim przypadku pytania brzmią: „Czy oryginalny kod był zgodny ze standardem?” Jeśli „tak”, to twój kolega nie powinien dotykać twojego kodu, chyba że zmienisz go funkcjonalnie. Jeśli „nie”, obawiam się, że twój kolega ma pełne prawo do uporządkowania kodu. Jako kierownik projektu cały czas to robię.

Jeśli nie używasz standardu kodowania, cały argument określający „dobry kod” staje się zbyt subiektywny. Dlatego powinieneś używać standardu kodowania :)


źródło
8

Jako jedna z tych osób (osób, które czasami formatują kod innych osób), głównym powodem, dla którego to robię, jest czytelność. Niektóre osoby są po prostu bardzo niechlujne ze swoimi wcięciami lub mieszaniem tabulatorów i spacji.

Najważniejszą rzeczą, którą mam w zwyczaju zmieniać, jest zmniejszanie długich linii, dzięki czemu mogę czytać całość bez przewijania w poziomie. Podzielę złożone instrukcje na osobne instrukcje lub ponownie sformatuję wywołania / deklaracje metod, aby wyświetlić jeden parametr w wierszu, jeśli nie wszystkie wygodnie mieszczą się w jednym wierszu. Będę również edytować komentarze, aby naprawić błędy w języku angielskim lub po prostu, aby wszystko było jaśniejsze.

Tak, mógłbym zostawić to w spokoju, ale wolę zmniejszyć wysiłek umysłowy wymagany do odczytania kodu.

Co powinieneś z tym zrobić? Po pierwsze, zastanów się, że może ta osoba ulepsza Twój kod. Ponadto powinieneś upewnić się, że masz pewien konsens w swoim zespole co do sposobu formatowania kodu. Jeśli każda osoba ma inne nawyki, spowolni wszystkich. Jeśli nie poprawiają twojego kodu i idą wbrew zasadom, musisz stawić im czoła. Jeśli to nie zadziała, być może będziesz musiał zaangażować innych.

Dan Dyer
źródło
To twoja czytelność, uważam, że niezauważalny kod SQL jest o wiele łatwiejszy do odczytania, ponieważ czytam szybko, a wcięty kod spowalnia mnie i utrudnia koncentrację.
HLGEM
6

Zapytaj ich, dlaczego to robią; prawidłowe wyjaśnienie może zmniejszyć twoją frustrację, ale powinieneś dać im znać, jak bardzo ci to przeszkadza. Kto wie, może myśleli, że wyświadczają ci przysługę i przestaną, gdy się dowiedzą, że cię obraża. Lub możesz mieć do czynienia z kimś, kto naprawdę cierpi na schorzenie.

JeffO
źródło
„Albo mają OCD i mogą potrzebować leków”. - najlepiej nie wspominać o tej części, jeśli chcesz pozostać przyjacielskim
Zaz
Zrobię poprawkę.
JeffO
5

Czy wolno mu to zrobić? Czy zmiany poprawiają kod? Jeśli tak, połknij swoją dumę. Jeśli uważasz, że jakość kodu uległa pogorszeniu, skontaktuj się ze współpracownikiem i zapytaj go, dlaczego odczuł potrzebę zmiany kodu bez widocznych korzyści. Jeśli dzieje się to z przekleństwem lub dlatego, że osoba błędnie uważa, że ​​jest lepsza od ciebie i nie możesz tego z nimi wypracować, weź to ze swoim szefem.

Chinmay Kanchi
źródło
5

IDE, podobnie jak Visual Studio, ma opcję o nazwie Format Document, która sformatuje kod zgodnie z regułami ustawionymi przez użytkownika w IDE. Może to być twój współpracownik używa tego (albo automatycznie bez wiedzy, albo przez celową aplikację). Być może ich IDE używa spacji zamiast tabulatorów i odwrotnie, i są one stosowane automatycznie, nawet nie wiedząc? Ale musisz z nimi porozmawiać, aby się dowiedzieć.

Nawiasem mówiąc, często będę ponownie formatować kod współpracowników, jeśli oczywiście nie postępuje zgodnie z jakimś schematem formatowania (tzn. Jest wszędzie). Jest to, miejmy nadzieję, subtelny sposób na ich zauważenie. (Jednak nie sformatowałbym go, gdyby był schludny, ale nie w moim guście).

Dan Diplo
źródło
1
„(Jednak nie sformatowałbym go, gdyby był schludny, ale nie do moich upodobań)” - bardzo ważna zasada, której należy przestrzegać, +1
Zaz
Nasze wytyczne programistyczne mają tendencję do umieszczania stylu kodu bardziej w „zalecanym” rogu. Automatycznie formatuję kod do zaleceń na poziomie plików, jeśli trudno mi je odczytać.
Joeri Sebrechts
3

Jeśli zmieni go tak, aby spełniał standardy kodowania twojego zespołu, powinieneś go przestrzegać następnym razem.

Jeśli zmieni to tak, że nie będzie już zgodne ze standardami kodowania twojego zespołu, poinformuj go, co robi źle, i pozwól mu to zmienić.

... Twój zespół ma zestaw standardów formatowania kodu, z których wszyscy korzystają, prawda?

Daenyth
źródło
2

Czasami zmieniam kod napisany przez niechlujnych współpracowników (lub naprawiam literówki w komentarzach). Wiedzą, że mam obsesję na punkcie formatowania i porządkowania kodu, dlatego pozwalają mi to robić bez narzekania. Czasami dają mi też darmową sodę lub ciasteczko.

Oczywiście jest to praca okazjonalna , ponieważ złamała funkcję „obwiniania” w SVN.

Jest to również bardzo podstawowy sposób na wykonanie przeglądu kodu (zwykle czytam większość kodu popełnionego przez moich współpracowników w modułach, nad którymi pracuję).

Wizard79
źródło
2

Konwencje Code jest odpowiedź. Powinieneś mieć go w pracy. Jeśli nie, zacznij już teraz (dobrym punktem wyjścia jest przewodnik po stylu Google ). Kiedy są zapisane (lub przynajmniej powszechnie znane) reguły, odpowiedź na twoje pytanie jest banalna.

Ilia K.
źródło
1

Czuję, że myślisz, że to obraźliwe ...? Na przykład sam bym natychmiast naprawił ten kod

int myFunction( ) {

    int i ;
  return  0;

}

zostać

int myFunction() {
    int i;
    return 0;
}

więc ... czy powinienem zostać ukarany z powodu mojego działania? W rzeczywistości mam mnóstwo dzienników SVN o treści „Formatowanie”. ;-)

tia
źródło
0

Użyj narzędzia do sprawdzania stylu

Zacznij używać StyleCop lub podobnego i egzekwuj reguły stylu kodu, a także nakładaj na wszystkich programistów obowiązek korzystania z niego. Cały kod będzie wyglądał tak samo bez wyjątku. I spotkaj się z mądrymi głowami, aby omówić najbardziej odpowiednie zasady dla Twojej organizacji. Mimo że domyślne reguły są już bardzo podobne do samego kodu frameworku .net.

To najłatwiejszy sposób na zrobienie tego. Zauważyłem, że poprawiam czyjś kod u jednego z moich poprzednich pracodawców, ponieważ ten inny facet pisał kod z nadmierną ilością pustych wierszy i bez żadnych wcięć. Przeciętny programista nie mógł odczytać kodu. Gdyby StyleCop istniał wtedy, wielu z nas byłby naprawdę szczęśliwy.

Robert Koritnik
źródło
Muszę głosować w dół. StyleCop to straszne wdrożenie porządnego pomysłu. 1) Działa po kompilacji, co czyni go głównym zabójcą czasu w dużych projektach 2) Domyślne reguły faktycznie zaprzeczają domyślnym ustawieniom VS w niektórych przypadkach 3) Niektóre reguły są całkowicie obłąkane. Narzeka na „//” bez spacji końcowej, a następnie każe użyć „////” Ponownie, po kompilacji. To najgorsza część. Nie byłoby źle, ale część po kompilacji naprawdę zabija cię przy dużym projekcie z długim czasem kompilacji.
MIA
Nie zgadzam się z tobą w wielu aspektach, które wskazałeś. Możesz skonfigurować sposób sprawdzania stylu. Zaimplementowałem nawet kilka własnych reguł, które zapewniają formatowanie, które chcę. Jeśli chodzi o prędkość, nie mogę powiedzieć, że jest świetna. ale na przyzwoitej maszynie powinno działać dobrze. Wystarczy pomyśleć o szybkości kopiarki C ++ na początku lat 90-tych, gdzie w międzyczasie można było przygotować herbatę. Podczas gdy kompilacja nie powiodła się !!!!!! ;)
Robert Koritnik
Właśnie zacząłem używać StyleCop, widząc, jak to idzie, i chociaż czasami jest trochę denerwujące, pomaga również znaleźć wiele błędów, które w przeciwnym razie pozostałyby niezauważone. Nie musisz go uruchamiać w ramach kompilacji i możesz po prostu uruchomić go na komputerze lokalnym, również dla pojedynczych plików. Abyś mógł z niego korzystać bez denerwowania innych programistów. Dodatkowo, jeśli nie podoba ci się reguła, możesz po prostu ją wyłączyć, aby nie wyrządzić prawdziwej szkody.
Anne Schuessler,
+1 To nie jest wyraźnie o StyleCop .. (StyleCop lub podobny ). To bardzo dobry pomysł. Zdefiniuj zestaw reguł, skonfiguruj wybrane narzędzie i bądź z nim na zawsze.
Bruno Schäpper 21.04.16
Obecnie mamy Grunta, Gulpa itp., Którzy mogą zrobić ten krok, tak jak robił to StyleCop w przeszłości.
Robert Koritnik 21.04.16
0

oto myśl, którą widziałem w Internecie na temat refaktoryzacji i może wyjaśnić, dlaczego ktoś mógłby dotknąć twojego kodu, aby go poprawić:

Dlaczego?

Istnieją dwa główne powody do refaktoryzacji:

  1. Aby poprawić kod / projekt przed zbudowaniem go na wierzchu: Naprawdę trudno jest wymyślić dobry kod przy pierwszej próbie. Pierwsza próba wdrożenia dowolnego wstępnego projektu pokaże nam, że źle zinterpretowaliśmy lub zapomnieliśmy trochę logiki.

  2. Aby dostosować się do zmian wymagań. Zmiana zachodzi w rozwoju oprogramowania; być wrażliwym na zmiany, lepiej mieć dobrą bazę kodu. Mamy dwie opcje dla obu scenariuszy: ścieżkę do kodu lub refaktoryzację. Łata kodu doprowadzi nas do niemożliwego do utrzymania kodu i zwiększy nasze zadłużenie techniczne, zawsze lepiej jest zrefaktoryzować.

Gdy?

  1. Im wcześniej tym lepiej, tym łatwiej.

  2. szybsze i mniej ryzykowne dla refaktoryzacji ostatnio zrefaktoryzowanego kodu zamiast oczekiwania na refaktoryzację, aż kod zostanie prawie ukończony.

Co?

  1. Cały kod i cały projekt są kandydatami do refaktoryzacji.

  2. Wyjątkiem jest brak refaktoryzacji czegoś, co może być działającym fragmentem kodu, którego jakość jest niska, ale z uwagi na fakt, że zbliża się termin, wolimy utrzymać nasz dług techniczny niż ryzykować planizację.

Musisz po prostu pozwolić mu dać z siebie wszystko, jeśli byłoby to świetne dla obu i zaoszczędzić czas w przyszłości!

Twoje zdrowie

Junior M.
źródło