W dniu 2011-04-14 09:18, wloochacz pisze:
> 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 :)

Może źle sprecyzowałem. Dla mnie istotne jest nie trzymanie się
standardów dla trzymania się standardów, ale osiągnięcie celu, jakim
jest czytelność kodu wystarczająca dla wszystkich członków zespołu.
Jeśli w ramach zespołu nie ma problemu, żeby czytać kod z pewnymi
różnicami w formatowaniu, to nie ma sensu tych różnic eliminować. Jeśli
są problemy, to oczywiście spisujemy, a najlepiej automatyzujemy. Takie
ustalenia (i rozwiązania) mogą się oczywiście zmieniać - byle szybko
reagować na potrzeby.


--
Paweł Kierski
n...@p...net