Czy tworzenie bloków kodu jest złą praktyką?


12

Czy w C ++ jest złą praktyką tworzenie bloków kodu wewnątrz niektórych funkcji, takich jak:

    bool f()
    {
       {
           double test = 0;

           test = // some other variable outside this function, for example.

           if (test == // some value)
             return true;
       }

       {
           double test = 0;

           test = // some variable outside this function, different from the last one.

           if (test == // some value)
             return true;
       }

       return false;

    }

Chodzi o to, aby użyć tej samej nazwy zmiennej „test” wiele razy, dla tego samego rodzaju procedury. W moim projekcie mam wiele zmiennych i wykonuję wiele testów. Naprawdę nie chcę ciągle tworzyć nowych zmiennych o różnych nazwach dla każdego testu, biorąc pod uwagę, jak testy są tak podobne.

Czy złą praktyką jest wstawianie bloków kodu, aby zmienne wykraczały poza zakres po każdym teście, a następnie mógłbym ponownie użyć ich nazw? Czy powinienem szukać innego rozwiązania? Należy zauważyć, że rozważałem użycie tego samego zestawu zmiennych dla wszystkich moich testów (i po prostu ustawienie ich wszystkich na 0 po zakończeniu każdego testu), ale miałem wrażenie, że może to być złą praktyką.


19
Gdybym ujawniał ten kod, powiedziałbym, abyś rozdzielił każdy z tych testów na osobne metody ... W rezultacie nie będziesz musiał używać bloków kodu, aby rozdzielić je osobno.
Maybe_Factor

1
@Maybe_Factor - Zgadzam się. Zaletą oddzielnych metod jest to, że można nazwać każdy blok, zapewniając bardziej czytelny kod.
mouviciel

@mouviciel Nie tylko bardziej czytelny kod, ale bardziej czytelne raporty z testów!
Maybe_Factor

@Maybe_Factor Nie zgadzam się. Przenoszenie rzeczy do oddzielnych funkcji ma negatywny wpływ na to, że wydają się być niewielkimi fragmentami funkcjonalności wielokrotnego użytku. Dobrze jest trzymać całą logikę funkcji w jednym miejscu.
Miles Rout

1
@MilesRout To nie jest jedna funkcja logiczna, to wiele testów jednostkowych dla funkcji w całości wciśniętej w jedną funkcję testową. Bloki kodu a funkcje w normalnym kodzie to zupełnie inna dyskusja.
Maybe_Factor

Odpowiedzi:


22

Bloki są całkowicie uzasadnione, jeśli używasz ich do określania zasięgu niektórych zasobów. Pliki, połączenia sieciowe, przydziały pamięci, transakcje w bazie danych, cokolwiek. W takich przypadkach blok jest faktycznie częścią logicznej struktury kodu: spawnujesz zasób, istnieje on przez pewien czas, a następnie znika w wyznaczonym czasie.

Ale jeśli wszystko, co robisz, to wybieranie nazwy , to powiedziałbym, że to zła praktyka. Ogólnie rzecz biorąc, oczywiście; mogą mieć zastosowanie specjalne okoliczności.

Na przykład, jeśli funkcja ta została wygenerowana przez jakiś system generowania kodu, środowisko testowe lub tym podobne, to rozsądne jest stosowanie bloków ze względu na zakres nazw. Ale mówisz o kodzie napisanym na potrzeby maszyny, a nie człowieka.

Jeśli człowiek pisze kod, w którym musi ponownie użyć nazw w ramach tej samej funkcji, powiedziałbym, że te bloki prawdopodobnie muszą być osobnymi funkcjami. Zwłaszcza jeśli te nazwy są używane z różnymi typami i / lub znaczeniami w tych blokach.


10

Tworzenie takich bloków nie jest złą praktyką. Tak działają lunety.

Zwykle odbywa się to podczas korzystania z RAII (Pozyskiwanie zasobów to inicjalizacja) i chcesz kontrolować, kiedy wywoływane są destruktory.

Jeśli będzie długo, rozważę przeniesienie tego kodu do jego własnej funkcji.

Moim zdaniem samo użycie go do recyklingu nazw zmiennych nie jest dobrym pomysłem. Ale widzę, że przydało się to w przypadkach o niskiej pamięci


Ponowne użycie lokalnych nazw zmiennych nie ma wpływu na użycie pamięci.
kevin cline

1
Czy nie uważasz, że inteligentny optymalizator mógłby użyć 1 lokalizacji pamięci dla 2 zmiennych?
Robert Andrzejuk

3
Tak. Ale może to również zrobić, jeśli są w tym samym zakresie, jeśli nie mają destruktorów.
Sebastian Redl,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.