Zwykle gdy nadzorujemy lub po prostu uczestniczymy w jakimś projekcie zależy nam na wysokiej jakości produktu końcowego, a co za tym idzie chcemy aby kod był napisany nie tylko poprawnie, ale też zgodnie z szeroko rozumianymi dobrymi praktykami. Co jednak zrobić, jeśli w naszym zespole są osoby, które uważają, że kod nie musi być piękny, ważne żeby robił to co do niego należy? Otóż, Eclipse może nam pomóc zdyscyplinować takie osoby i wymusić pewne dobre praktyki. Na czym ta pomoc polega? W łatwy sposób na poziomie całej przestrzeni pracy (ang. workspace) lub też na poziomie projektu możemy ustawić jaki kod kompilator ma uważać za błędny, o jakim ma ostrzegać, a co po prostu ignorować.
Załóżmy, że chcemy ustawić te opcje dla konkretnego projektu. W widoku Package Explorer klikamy prawym przyciskiem myszy na projekcie i wybieramy opcję Properties. Dalej wybieramy Java Compiler - >Errors / Warnings:
Zaznaczamy opcję Enable project specific settings, co pozwoli nam na dostosowanie ustawień wyłącznie dla wybranego przez nas projektu.
Po prawej stronie zobaczymy rozwijane kategorie kryjące różnorakie elementy, którym warto się przyjrzeć i skonfigurować według naszych preferencji. Na przykład jeśli nie chcemy aby programiści tworzyli metody o takiej samej nazwie jak konstruktor to ustawiamy wartość Method with a constructor name na Error, wówczas jeśli programista będzie chciał stworzyć taką metodę to kompilator mu na to nie pozwoli:
Możemy też np. uczulić programistę na różne konstrukcje - i tak jeśli zaznaczymy opcję Redundant null check, to jeśli kompilator wykryje niepotrzebne sprawdzanie wartości null to poinformuje o tym programistę ostrzeżeniem:
Myślę, że warto się przyjrzeć tym opcjom i dostosować je do swoich przyzwyczeń lub też standardów, aby nasz kod stawał się jak najlepszy, bo chyba nikt nie lubi później długimi godzinami zastanawiać się "Co ja wtedy miałem na myśli?", prawda?
środa, 27 sierpnia 2008
Ustawienia kompilatora dla projektów Javy.
Subskrybuj:
Komentarze do posta (Atom)
4 komentarze:
Święta prawda. Większość (z wyjątkiem takich pierduł jak nieeksternalizowane stringi, bez przesady ;-]) z tych rzeczy albo pokazuje źródło POTENCJALNEGO błędu, albo po prostu niechlujstwo w kodzie (pozapominane prywatne metody, zmienne, nigdy nie używane parametry itp. itd.). Ja zawsze ustawiam prawie wszystkie z nich na "warning" i ścigam patafianów za każdym razem jak submitują kod z warningami ;-] Wśród takich co przychodzą do pracy prosto po studiach (niemieckich) świadomość konwencji kodowania i w ogóle pisania czystego i czytelnego(!) kodu jest niestety z reguły zerowa :-/
No właśnie od takich "bez przesady" zwykle się zaczyna ;)
Sam się zdziwiłem, że w projektach powstających pod szyldem Eclipse'a eksternalizowanie stringów jest jednym z warunków, żeby kod mógł być zaakceptowany i wrzucony do repozytorium.
Daj spokój, nie ten poziom... Ja nie umiem patafianów nauczyć, że nie pisze się funkcji długich na 3 ekrany (nie mówiąc o tym, że niektórzy potrafią pisać nazwy funkcji z wielkich liter a klas z małych), a tu eksternalizacja stringów... Skrajny debilizm normalnie, najgorsze jest, że jak dostaną zjebkę to głowami kiwają a potem i tak piszą swoje. Czasami nie mam już do nich sił, bo po prostu łapy opadają ze świstem.
To tak jakby ktoś się pytał, dlaczego w Niemczech potrzebują programistów z Polski, żółci trochę upuściłem ;-/
Prześlij komentarz