[Marmite]

Pytanie w stylu "straszna pierdoła, ale w sumie mnie nurtuje": Wszędzie zaleca się, żeby wartości przechowujące booleany zaczynały się od "is" i dalej przymiotnik. No dobra, a co z takimi zmiennymi jak

doesPathContainStartElement

? Brzmi okej czy raczej zamieniać na dziwnie brzmiącą formę z is (

isPathContainingStartElement

- brzmi niegramatycznie, w życiu bym tak nie powiedział) czy może jeszcze inaczej to rozwiązać (

isStartElementContainedInPath

etc)?

#programowanie #cleancode

[zakowskijan72]

Wszędzie zaleca się, żeby wartości przechowujące booleany zaczynały się od "is"

@Marmite: Nie wszędzie. Gdzieniegdzie zaczynają się od 'b', a jeszcze gdzie indziej nie zaczynają się wcale.

[Nadrill]

@Marmite: isAPathThatContainsStartElement ( ͡° ͜ʖ ͡°)

[Marmite]

@zakowskijan72: (#) Mówimy o clean code.

@Nadrill: (#) To chyba raczej

isThatPathAPathThatContainsStartElement

xD ale to już straszny dziwoląg

[a.....s]

@Marmite: za zmienne boolowe o dlugosci nazwy wiekszej niz 10 znakow powinno sie rozstrzelac

[Nadrill]

@aryss: bullshit

[Marmite]

@aryss: (#) Tja, lepsza nazwa to chociażby "x", albo "foo". Zmienna ma mówić o sobie wszystko.

[Pruderyjny]

@aryss: chyba pisze w notatniku i nie zna potęgi ctrl + spacja

[a.....s]

@Pruderyjny: przecież w przypadku długich nazw które nie posiadają skrótów określen autouzupełnianie niewiele pomaga bo i tak trzeba wpisac n początkowych znaków ( tu wystarczy że autor pododaje jeszcze sobie inne flagi sprawdzajace czy sciezka zawiera inne #!$%@?). Tworząc takie potworki możemy dojść do sytuacji gdzie zmienna będzie dłuższa niż metoda ją ustawiająca

[a.....s]

@Pruderyjny: + w normalnych IDE pod ctrl+spacjja i tak prezentowane oprócz nazwy jest komentarz z deklaracji zmeinnej/klasy tak wiec tam mozna zawrzec szeroki opis i przegladac przewijajac strzalka w dol propozycje ;)

[Marmite]

@aryss: (#) No ja szczerze powiedziawszy wolę zobaczyć w kodzie coś takiego:

if(!doesPathContainStartElement()) {

 addStartElementToPath();

}

niż jakieś dziwne skróty i sprawdzać w komentarzach co one znaczą.

Ale my tu nie o tym.

[Pruderyjny]

@aryss: Kod powinien byc oczywisty i sam się komentować, jeżeli musisz pisać komentarz do krótkiego kodu znaczy, że zrobiłeś coś bardzo źle.

Tak jak napisał @Marmite jest znacznie czytelniejsze niż jakieś komentarze do zmiennych ala albo dupa D:

[a.....s]

@Marmite: @Pruderyjny: no mi chodzilo o delikatnie mowiac bardziej skomplikowane warunki gdzie logika biznesowa wymusza stosowanie wiekszej ilosci flag nizli 1 a dodatkowo czesto bywa tak ze programista nie zna tematyki o czym tworzy aplikacje i komentarze nawet do #!$%@? zmiennych bywaja przydatne;)

[Marmite]

bardziej skomplikowane warunki gdzie logika biznesowa wymusza stosowanie wiekszej ilosci flag nizli 1

@aryss: (#) Jak w ifie jest dużo warunków, to rozwalasz je na osobną funkcję albo wiele funkcji

[a.....s]

@Marmite: no i wowczas kazda z tych funkcji jest zwracajaca wartosc true/false zmienna boolowska i mozemy miec sytuacje gdzie nie mozna tego bardziej rozbic:P

[Marmite]

@aryss: (#) No i chyba o to nam chodziło?

@zakowskijan72: (#) Wypowiadamy się na temat.

[a.....s]

@Marmite: szczerze mam wrazenie ze grochem o sciane rzucam wiec krotko napisze raz jeszcze ze:

moim zdaniem zmienne boolowskie powinny byc nazywane jasno ale skrotowo bez kobyl ktore zaprezentowales juz w 1 przykladzie. A teraz grzecznie wracam do ogladania meczu

[Marmite]

@aryss: (#) Ja też mam wrażenie, ze grochem o sciane rzucam. Taki fragment kodu:

bool doesPathContainStartElement;

jest o wiele lepszy niż taki

bool isContained; //tells if a start element is contained in the path

Miłego oglądania.

[G.....n]

@Marmite: (#) A gdyby tak użyć jakiegoś metaprogramowania?

Np. tablica obiektów typu {

'condition': function(){

return warunek;

},

'success': function() {

},

'fail': function() {

}

}
?