Czy programiści powinni używać zmiennych boolowskich do „dokumentowania” swojego kodu?

Czytam Code Complete McConella , a on omawia użycie zmiennych boolowskich do dokumentowania kodu. Na przykład zamiast:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
       ...
}

On sugeruje:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

Wydaje mi się to logiczne, dobre i bardzo samodokumentujące. Jednak waham się, czy zacząć regularnie używać tej techniki, ponieważ prawie nigdy się z nią nie spotkałem; i być może byłoby to mylące tylko dlatego, że jest rzadkie. Jednak moje doświadczenie nie jest jeszcze zbyt rozległe, więc interesuje mnie opinia programistów na temat tej techniki i byłbym ciekawy, czy ktoś używa tej techniki regularnie lub często ją widzi podczas czytania kodu. Czy warto zastosować konwencję / styl / technikę? Czy inni programiści to zrozumieją i docenią, czy też uznają to za dziwne?

Dzielenie wyrażenia, które jest zbyt zagnieżdżone i skomplikowane na prostsze wyrażenia podrzędne przypisane do zmiennych lokalnych, a następnie złożone razem, jest dość powszechną i popularną techniką - zupełnie niezależnie od tego, czy wyrażenia podrzędne i / lub ogólne wyrażenie są prawie każdy inny typ. Przy dobrze dobranych nazwach, gustowna dekompozycja tego rodzaju może zwiększyć czytelność, a dobry kompilator nie powinien mieć problemu z wygenerowaniem kodu odpowiadającego oryginalnemu, skomplikowanemu wyrażeniu.

Niektóre języki, które nie mają pojęcia „przypisania” jako takiego, takie jak Haskell, wprowadzają nawet wyspecjalizowane konstrukcje pozwalające na użycie techniki „nadaj nazwę podwyrażeniu” ( whereklauzula w języku Haskell) - wydaje się, że popularność danej techniki! -)

Użyłem go, chociaż zwykle zawijam logikę boolowską w metodę wielokrotnego użytku (jeśli jest wywoływana z wielu lokalizacji).

Pomaga w czytelności, a kiedy zmienia się logika, wystarczy zmienić ją w jednym miejscu.

Inni zrozumieją to i nie uznają tego za dziwne (z wyjątkiem tych, którzy piszą tylko funkcje tysiąca linii, to znaczy).

Staram się to robić wszędzie, gdzie to możliwe. Jasne, używasz „dodatkowej linii” kodu, ale jednocześnie opisujesz, dlaczego dokonujesz porównania dwóch wartości.

W twoim przykładzie patrzę na kod i zadaję sobie pytanie „w porządku, dlaczego osoba widząca wartość jest mniejsza niż 0?” W drugiej wyraźnie mi powiesz, że niektóre procesy zostały zakończone, kiedy to nastąpi. W drugim nie zgadnij, jaki był twój zamiar.

Najważniejsze dla mnie jest, gdy widzę metodę: DoSomeMethod(true); Dlaczego jest automatycznie ustawiona na wartość true? Jest dużo bardziej czytelny

bool deleteOnCompletion = true;

DoSomeMethod(deleteOnCompletion);

Dostarczona próbka:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

Można też przepisać na metody poprawiające czytelność i zachowujące logikę boolowską (jak wskazał Konrad):

if (IsFinished(elementIndex) || IsRepeatedEntry(elementIndex, lastElementIndex)){
   ...
}

...

private bool IsFinished(int elementIndex) {
    return ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
}

private bool IsRepeatedEntry(int elementIndex, int lastElementIndex) {
    return (elementIndex == lastElementIndex);
}

Ma to oczywiście swoją cenę, czyli dwie dodatkowe metody. Jeśli będziesz to robić często, może to uczynić Twój kod bardziej czytelnym, ale Twoje klasy będą mniej przejrzyste. Ale z drugiej strony możesz również przenieść dodatkowe metody do klas pomocniczych.

Jedynym sposobem, w jaki mogłem zobaczyć, że to idzie źle, jest to, że fragment logiczny nie ma nazwy, która ma sens, a nazwa została wybrana.

//No clue what the parts might mean.
if(price>0 && (customer.IsAlive || IsDay(Thursday)))

=>

first_condition = price>0
second_condition =customer.IsAlive || IsDay(Thursday)

//I'm still not enlightened.
if(first_condition && second_condition)

Zwracam na to uwagę, ponieważ często tworzy się reguły takie jak „komentuj cały kod”, „używaj nazwanych wartości logicznych dla wszystkich kryteriów if z więcej niż 3 częściami” tylko po to, aby uzyskać komentarze, które są semantycznie puste w następującym sortowaniu

i++; //increment i by adding 1 to i's previous value

Robiąc to

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

usuwasz logikę z mózgu i umieszczasz ją w kodzie. Teraz program wie, co masz na myśli.
Kiedykolwiek nazwać coś, co daje mu fizyczną reprezentację. Istnieje.
Możesz nim manipulować i używać go ponownie.

Możesz nawet zdefiniować cały blok jako predykat:

bool ElementBlahBlah? (elementIndex, lastElementIndex);

i rób więcej rzeczy (później) w tej funkcji.

Jeśli wyrażenie jest złożone, to albo przenoszę je do innej funkcji, która zwraca boolnp., isAnEveningInThePubAGoodIdea(dayOfWeek, sizeOfWorkLoad, amountOfSpareCash)Albo ponownie rozważam kod, aby takie złożone wyrażenie nie było wymagane.

Pamiętaj, że w ten sposób obliczasz więcej niż to konieczne. Ze względu na wyjęcie warunków z kodu, zawsze obliczasz oba z nich (bez zwarcia).

Po to aby:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
   ...
}

Po transformacji staje się:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) |
   (elementIndex == lastElementIndex)){
   ...
}

W większości przypadków nie jest to problem, ale nadal w niektórych może oznaczać gorszą wydajność lub inne problemy, np. Gdy w drugim wyrażeniu założysz, że pierwszy zawiódł.

Myślę, że lepiej jest tworzyć funkcje / metody zamiast zmiennych tymczasowych. W ten sposób zwiększa się czytelność również dlatego, że metody stają się krótsze. Książka Martina Fowlera Refactoring zawiera dobre rady dotyczące poprawy jakości kodu. Refaktoryzacje związane z konkretnym przykładem nazywają się „Zastąp temp. Zapytaniem” i „Wyodrębnij metodę”.

Osobiście uważam, że to świetna praktyka. Jego wpływ na wykonanie kodu jest minimalny, ale przejrzystość, jaką może zapewnić, jeśli jest właściwie używana, jest nieoceniona, jeśli chodzi o późniejszą konserwację kodu.

jeśli metoda wymaga powiadomienia o sukcesie: (przykłady w c #) Lubię używać

bool success = false;

zacząć. kod nie działa, dopóki nie zmienię go na:

success = true;

potem na końcu:

return success;

Myślę, że to zależy od stylu preferowanego przez Ciebie / Twój zespół. Refaktoryzacja „Wprowadź zmienną” może być przydatna, ale czasami nie :)

I nie zgadzam się z Kevinem w jego poprzednim poście. Jego przykład, jak przypuszczam, nadający się do użytku w przypadku, gdy wprowadzona zmienna może zostać zmieniona, ale wprowadzenie jej tylko dla jednego statycznego boolean jest bezużyteczne, ponieważ w deklaracji metody mamy nazwę parametru, więc po co powielać ją w kodzie?

na przykład:

void DoSomeMethod(boolean needDelete) { ... }

// useful
boolean deleteOnCompletion = true;
if ( someCondition ) {
    deleteOnCompletion = false;
}
DoSomeMethod(deleteOnCompletion);

// useless
boolean shouldNotDelete = false;
DoSomeMethod(shouldNotDelete);

Z doświadczenia wiem, że często wracałem do starych scenariuszy i zastanawiałem się „o czym ja do cholery myślałem wtedy?”. Na przykład:

Math.p = function Math_p(a) {
    var r = 1, b = [], m = Math;
    a = m.js.copy(arguments);
    while (a.length) {
        b = b.concat(a.shift());
    }
    while (b.length) {
        r *= b.shift();
    }
    return r;
};

który nie jest tak intuicyjny jak:

/**
 * An extension to the Math object that accepts Arrays or Numbers
 * as an argument and returns the product of all numbers.
 * @param(Array) a A Number or an Array of numbers.
 * @return(Number) Returns the product of all numbers.
 */
Math.product = function Math_product(a) {
    var product = 1, numbers = [];
    a = argumentsToArray(arguments);
    while (a.length) {
        numbers = numbers.concat(a.shift());
    }
    while (numbers.length) {
        product *= numbers.shift();
    }
    return product;
};

Rzadko tworzę oddzielne zmienne. To, co robię, gdy testy stają się skomplikowane, to zagnieżdżanie IF i dodawanie komentarzy. Lubić

boolean processElement=false;
if (elementIndex < 0) // Do we have a valid element?
{
  processElement=true;
}
else if (elementIndex==lastElementIndex) // Is it the one we want?
{
  processElement=true;
}
if (processElement)
...

Przyznaną wadą tej techniki jest to, że następny programista, który się pojawi, może zmienić logikę, ale nie zadaje sobie trudu, aby aktualizować komentarze. Wydaje mi się, że jest to ogólny problem, ale wiele razy widziałem komentarz mówiący „Sprawdź identyfikator klienta”, a następny wiersz dotyczy sprawdzenia numeru części lub czegoś podobnego i zastanawiam się, gdzie klient id wchodzi.