W dniu 2011-04-14 08:44, Paweł Kierski pisze:
> W dniu 2011-04-13 21:30, A.L. pisze:
> [...]
>> Niby dlaczego?... U mnie w firmie zawsze jest wiecej do srobienai niz
>> "mocy przerobowych" co nie przeszkadza miec rozne dokumenty pod
>> wspolna nazwa "programming standards" ktorych przestzreganie jest
>> wymuszane w sposob drakonski, poczawszy od zautomatyzoanych narzedzi
>> po manualne "code reviews". Dzieje sie tak, albowiem zauwazono (nie
>> tylko w mojej firmie) ze "strata czasu" zwiazana z porzadnym
>> kodowaniem jest znacznie mniejsza nis rzeczywista strata czasu
>> znacznie pozniej, gdy przyjdzie modyfikowac program lub szukac bledow.
>
> Wydaje mi się, że również na polu "standaryzacji" trzeba zachować umiar
> i dopasować narzędzia do zastosowań. Np. nie widzę specjalnego sensu
> w standaryzowaniu pierdół w postaci "Stawiamy spację między 'if'
> a nawiasem czy nie?". Choć już otwieranie bloków (nawias w tej samej
> linii lub następnej) bywa istotne dla czytelności kodu przez większość
> - wypada się zastanowić, czy warto wymuszać na ludziach, czy może
> przygotować środowisko tak, żeby każdy pisał, jak chce, a automat
> utrzymywał spójność w repozytorium.
>
> Po za tym - inaczej to będzie wyglądało w zespole kilkuosobowym,
> a inaczej w projekcie tworzonym we współpracy kilkunastu takich
> zespołów. Mniejsze projekty mogą sobie pozwolić na nieco większą
> elastyczność.
Nie zgadzam się z Tobą - ja mam mikry zespół składający się z kilku
osób, ale mam też pewien dokument w którym w dość restrykcyjny sposób
opisałem wszystkie takie jak je nazywasz - pierdoły.
Zgodziłem się na jeden kompromis - wszystko to co opisałem, uzyskuję za
pomocą automatycznego formatowania kodu wbudowanego w IDE.
Nie było moim celem zmuszanie kogokolwiek do trzymania się pierdół,
tylko do zachowania konwencji.
Wszyscy, którzy uważają takie banalne zasady za pierdoły, niech zaczną
recenzować cudzy kod. Mi się to zdarza częściej niż pisanie własnego - i
spójność w tym przypadku ma pierwszorzędne znaczenie na szybkie
ogarnięcie danego kodu.
Co więcej, jak się okazuje po moich znajomych - wszyscy którzy nie mieli
takich standardów cierpieli z tego względu niemożebne katusze, musząc
zrecenzować/poprawić cudzy kod, w którym każdy pisał jak chciał i nie
wychodził poza swoją działkę.
Także, zgadzam się w 150% z A.L - i szczerze mówiąc, mam generalnie w
du..ie ewentualne psioczenie zespołu na takie "upierdliwości"; szkoda
czasu na dyskusje na ten temat z kimś, kto tego nie rozumie ;-)

Za to chętnie zobaczyłbym jakieś inne, ciekawe "programming standards" -
inspiracji nigdy za mało :)

--
wloochacz