Czy uważacie, że źle sformatowany kod (złe wcięcia, nieużywane importy w klasach, źle opisane parametry w annotacjach itp.), to powód, aby odrzucić code review i zawrócić go do programisty?
@krejdd: Zdecydowanie. Niewątpliwie. Absolutnie. Bezapellacyjnie. Oczywiście. <- wybierz, które słowo z nich najbardziej lubisz i będzie to odpowiedź na Twoje pytanie :)
@krejdd: To nie wiesz, jakie macie standardy w projekcie? Skoro już robisz/dostałeś code review, to za późno na takie rozkminy. Działa się według wcześniej ustalonych standardów.
Jeśli chodzi zaś o ustalanie standardów w projekcie, to tak, głosowałbym za tym, żeby za takie coś #!$%@?ć.
@krejdd: Wyobraź sobie, że za rok albo dwa ktoś nie uczestniczący w obecnym projekcie może dostać taki wall od text (i to jeszcze źle opisany) do wykorzystania bądź modyfikacji. Albo gorzej, TY dostaniesz coś takiego ( ͡°͜ʖ͡°).
@krejdd: jest sporo style checkerów, które nie pozwolą wypchnąć Ci zmian dopóki nie dostosujesz stylu do ogólnie założonego, nie pousuwasz/posortujesz importów etc. Ale odpowiadając na pytanie - tak
@krejdd: nie, uważam za to, że programiści, którzy mająz tym problem, powinni iść na ASP a nie pisać kod. Widziałem takie zajebiste code review - wszystkie komentarze to ,,brak nowej linii, brak spacji, brak gwiazdki".. Z drugiej strony, jeśli np ustalasz razem z teamem, że trzymamy się danych zasad, to profesjonalizm nakazuje się ich trzymać, tym bardziej, że można podpiąć formatowanie pod commitowanie by mieć delikatne kwiatuszki-artystów z głowy.
@krejdd: Na przykladzie Javy (bo nie wiem w czym kodzisz): checkstyle, findbugs, pmd, cpd, wsio. Nie zbudujesz, jak kod bedzie mial braki. Wtedy podczas CR mozna sie skupic na powazniejszych sprawach niz zle sformatowane linie.
@alex-fortune: programiści którzy nie potrafią wcisnąć "reformat file" przed commitem powinni się wstydzić że ktoś im musi pisać "brak nowej linii, brak spacji, brak gwiazdki". Code review które widziałeś obciążało autora kodu, nie recenzji (no chyba że projekt nie miał ustalonego standardu kodowania a autor kodu był spójny z resztą pliku i recenzent czepiał się bezpodstawnie)
Formatowanie kodu to nie fanaberia ani sztuka jak twierdzisz. Potem kolejny programista przychodzi i poprawia
programiści którzy nie potrafią wcisnąć "reformat file" przed commitem powinni się wstydzić że ktoś im musi pisać "brak nowej linii, brak spacji, brak gwiazdki". Code review które widziałeś obciążało autora kodu, nie recenzji (no chyba że projekt nie miał ustalonego standardu kodowania a autor kodu był spójny z resztą pliku i recenzent czepiał się bezpodstawnie)
@sakfa: Waćpan wybaczy, po prostu gdzieś to zupełnie na końcu listy u mnie leży, pewnie dlatego,
Rownie dobrze moglbym "kopać po ryju" ludzi, którzy nie potrafią stosować podstawowych wzorców projektowych, robią kurtyzanę z złożoności obliczeniowej bądź stosują złe narzędzia do problemów
@alex-fortune: no widzisz nie do końca. Stosowanie podstawowych wzorców projektowych, dobranie dobrych algorytmów czy wybór narzędzia to problemy trudne. Ludzie robią to źle często nie z lenistwa tylko z braku kompetencji - należy więc ich edukować, zwolnić bądź zaakceptować fakt że są słabszymi koderami i
Formatowanie kodu to natomiast problem banalny, brak dobrego formatowania wynika tylko i wyłącznie z lenistwa, nie ma tu żadnego innego usprawiedliwienia.
@sakfa: Może postawię to trochę inaczej, bo chyba zostałem źle zrozumiany - dla mnie kod mógłby być niesformatowany i mnie to nie razi, prędkość rozczytywania jest u mnie taka sama, bo nie zwracam na rzeczy nieistotne semantycznie uwagi. Natomiast zważywszy na to, że pracuję z innymi ludźmi, jeśli np umawiamy
#programowanie
Zdecydowanie. Niewątpliwie. Absolutnie. Bezapellacyjnie. Oczywiście. <- wybierz, które słowo z nich najbardziej lubisz i będzie to odpowiedź na Twoje pytanie :)
Jeśli chodzi zaś o ustalanie standardów w projekcie, to tak, głosowałbym za tym, żeby za takie coś #!$%@?ć.
Formatowanie kodu to nie fanaberia ani sztuka jak twierdzisz. Potem kolejny programista przychodzi i poprawia
@sakfa: Waćpan wybaczy, po prostu gdzieś to zupełnie na końcu listy u mnie leży, pewnie dlatego,
@alex-fortune: no widzisz nie do końca. Stosowanie podstawowych wzorców projektowych, dobranie dobrych algorytmów czy wybór narzędzia to problemy trudne. Ludzie robią to źle często nie z lenistwa tylko z braku kompetencji - należy więc ich edukować, zwolnić bądź zaakceptować fakt że są słabszymi koderami i
@sakfa: Może postawię to trochę inaczej, bo chyba zostałem źle zrozumiany - dla mnie kod mógłby być niesformatowany i mnie to nie razi, prędkość rozczytywania jest u mnie taka sama, bo nie zwracam na rzeczy nieistotne semantycznie uwagi. Natomiast zważywszy na to, że pracuję z innymi ludźmi, jeśli np umawiamy