[S.....r]

Hej mirki z #programowanie #java
Co jest lepszą praktyką?

void a(){
 if(this.b){return;}
 //kod do wykonania
}

Czy:

void a(){
 if(!this.b){
 //kod do wykonania
 }
}

[pitu120]

@SiarkoWodor: Może nie programuje w javie. Lecz używam pierwsze sposobu. Wszyscy w firmie również, tylko my nie programujemy bo #php mocno. ( ͡º ͜ʖ͡º)

[Namenick]

@SiarkoWodor: No jasne że drugi kod, pierwszy ma błąd ( ͡° ͜ʖ ͡°)

[S.....r]

@pitu120: Lubię php, szacuneczek ( ͡° ͜ʖ ͡°)ﾉ⌐■-■

[GotoFinal]

@SiarkoWodor: No ja zazwyczaj używam pierwszego, inaczej kilka prostych walidacji/sprawdzeń a już masz 3+ poziomy wcięć i potem kod wychodzi za ekran.

[S.....r]

@Namenick: W którym miejscu?

[Namenick]

@SiarkoWodor: A tak serio, to takie pytanie jest bez sensu, wszystko zależy od tego co ma się wykonać.

[sorhu]

@SiarkoWodor: Drugi.

[kasa]

@SiarkoWodor: Poczytaj o GuardClause (np. http://c2.com/cgi/wiki?GuardClause), preconditions, etc. W tematyce czystego kodu oczywiście polecam jeszcze książke Roberta C. Martina - Clean Code.

[c.....g]

@SiarkoWodor: wąsy nie są zamknięte poprawnie.

[T.....0]

@SiarkoWodor: Pierwszy tylko bez tych {} -
if(!b)
return;

[sorhu]

@Thh0: Toż to niezgodne z dobrymi praktykami te klamry pomijać.

[S.....r]

@sorhu: Popieram, kod staje się wtedy nieco mniej czytelny.

[GotoFinal]

@Namenick: @chilling: Niby jaki błąd? Wszystko jest poprawnie, co najwyżej kod ciaśniej zapisany bo wykop i tak pierniczy formatowanie. Ale poprawny.

[sorhu]

@SiarkoWodor: A bez klamr to łatwiej o błąd jak ktoś coś miałby potem zmieniać.

[c.....g]

@GotoFinal: faktycznie przeoczyłem klamrę. Pół piwa za dużo.

[Leihto]

@SiarkoWodor: Oba są poprawne, lecz reguły clean code mówią aby używać drugiego sposobu, bo np. Przy większym ciele metody, wykonanie przerwania wprowadza chaos i trochę szum informacyjny

[S.....h]

@SiarkoWodor: Jasne że drugi.
1. Masz pewność że debuger się nie popieprzy. To akurat jest prosty przykład, ale naprawdę, jest sporo przypadków, kiedy przez takie returny możesz stracić synchro.
2. Jest ogólna zasada, jeden return na funkcję - czysty kod. Każdy dodatkowy return zwiększa skomplikowalność metody o jeden. A chyba dobrą praktyką jest trzymać poziom na max 9.
3. Jeśli przez brak returnów na poczatku, masz problemy potem ze wcięciami,

[K.....a]

@SiarkoWodor: pierwszy jest łatwy do debugowania, łatwiejszy w czytaniu jak i też rozszerzalny , bo możesz dodać nowe walidacje. Ten 2 styl robią amatorzy, którzy zaczynają przygodę z programowaniem.

Polecam zobaczyć frameworki jak są pisane przez profesjonalistów.

[GotoFinal]

@Sarseth:
1. o.O Nie wiem w jakim języku piszesz, ale na pewno nie w javie. Prawie cały czas mam odpalony debugger i restartuje tylko po dodaniu klasy/metody/pola. Masz jakiś dziwny debugger.
2. Niby tak, ale utrzymywanie go tak na siłę, jak w linku od @kasa wygląda źle i czyta się źle. A i dla javy takie rozwiązanie jest normalne i wręcz oczekiwane.
3. Nawet te 3 wcięcia powodują że