Po co używać #if 0 do komentowania bloku?

Komentarze są komentarzami. Opisują kod.

Kod, który jest wyłączany z kompilacji to kod, a nie komentarze. Często będą to Komentarze opisujące kod, który nie jest kompilowany, na razie/

Są to dwa różne pojęcia, a wymuszanie tej samej składni uderza mnie jako błąd.

Poza problemem nie zagnieżdżania komentarzy W Stylu C, wyłączenie bloków kodu za pomocą #if 0 ma tę zaletę, że może być zwinięte, jeśli używasz edytora obsługującego składanie kodu. Jest to również bardzo łatwe do zrobienia w dowolnym edytorze, podczas gdy wyłączenie dużych bloków kodu z komentarzami w stylu C++może być nieporęczne bez obsługi edytora/makr.

Ponadto wiele #if 0 bloków ma również else. Daje to łatwy sposób na zamianę pomiędzy dwoma implementacjami/algorytmami i jest prawdopodobnie mniej podatne na błędy niż masowe komentowanie jednej sekcji i masowe komentowanie drugiej. Jednak lepiej byłoby użyć czegoś bardziej czytelnego, takiego jak #if DEBUG w tym przypadku.

To całkiem idiomatyczne C. Nie widzę w tym nic złego. Nie jest to piękny kawałek kodu, ale jest łatwy do odczytania i jest jasne, co się dzieje i dlaczego, nawet bez kontekstu.

Nazwy zmiennych mogłyby być lepsze i prawdopodobnie bezpieczniejsze byłoby użycie snprintf lub strncpy.

Mogę dokonać drobnej zmiany:

char username[32];
strncpy(username, 30, (pwbuf ? pwbuf->pw_name : user_id));
username[31] = '\0';

Jeśli chodzi o blokowe komentowanie za pomocą //, jednym z powodów, dla których mogę myśleć, jest to, że jeśli sprawdzisz ten kod w swoim systemie kontroli źródła, dziennik winy pokaże ci jako ostatni edytor tych linii kodu. Chociaż prawdopodobnie chcesz, aby Komentarz został przypisany do Ciebie, w tym samym czasie sam kod jest również przypisywany do ciebie. Oczywiście, możesz wrócić i spojrzeć na poprzednie wersje, jeśli chcesz sprawdzić dziennik winy dla "prawdziwego" autora kodu, ale byłoby to zaoszczędź czas, jeśli zachowano te informacje w bieżącej wersji.

Oczywiście, każdy ma swoje zdanie na ten temat. Więc oto moje:

Ja bym nigdy nie pisał kodu jak wyżej i nie myślał o każdym, kto to zrobił. Nie mogę zliczyć, ile razy ludzie myślą, że można uciec bez aparatów, a potem zostać przez nie ugryziony.

Umieszczenie instrukcji control w tej samej linii co blok kodu jest jeszcze gorsze; brak wcięcia utrudnia zobaczenie sterowania przepływem podczas czytania. Once you ' ve been kodowanie przez kilka lat przyzwyczajasz się do szybkiego i dokładnego odczytywania i interpretacji kodu, o ile możesz polegać na pewnych wskazówkach wizualnych. Obejście tych wskazówek dla "szczególnych przypadków" oznacza, że czytelnik musi zatrzymać się i zrobić podwójne ujęcie, bez ważnego powodu.

#if (0), z drugiej strony, jest ok podczas programowania, ale powinien zostać usunięty, gdy kod będzie "stabilny" (lub przynajmniej zastąpić 0 jakąś sensowną nazwą symbolu preprocesora).

Woah tam! Nie przesadzaj...

Styl inline jest lepszy dla zwięzłości pionowej... można łatwo podzielić na 4, więcej linii

if (pwbuf) 
  sprintf(username,"%s",pwbuf->pw_name); 
else 
  sprintf(username,"%d",user_id); 

if (pwbuf) 
{
  sprintf(username,"%s",pwbuf->pw_name); 
}
else
{ 
  sprintf(username,"%d",user_id); 
}

Uwagi powyżej. Ale monitory są panoramiczne i w ogóle, w dzisiejszych czasach, nie mam nic przeciwko

if (pwbuf) sprintf(username,"%s",pwbuf->pw_name);
else       sprintf(username,"%d",user_id);

Zawsze wydaje się mieć zbyt dużo miejsca w poziomie, a za mało miejsca w pionie na moim ekranie!

Ponadto, jeśli blok kodu ma już dyrektywy preprocesora, nie używaj #if 0; jeśli kod ma już komentarze blokowe, nie używaj /* */. Jeśli ma już oba, albo użyj edytora, który ma ctrl+/, aby skomentować wiele linijek. Jeśli nie, jesteś wypchany., Usuń kod natychmiast!

if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);

#if 0
....
#endif

Dobrze włączyć bloki kodu debugowania czy nie. Ponadto uniknąłby błędów kompilacji związanych z próbami zablokowania komentarzy tego typu:

/* line comment */
...
/* line comment again */

Ponieważ komentarze bloku C nie zagnieżdżają się.

Bardzo sporadycznie używam bardziej zwięzłego stylu, gdy wspiera symetrię kodu, a linie nie stają się zbyt długie. Weźmy następujący przykład:

if (strcmp(s, "foo") == 0)
{
    bitmap = 0x00000001UL;
    bit = 0;
}
else if (strcmp(s, "bar") == 0)
{
    bitmap = 0x00000002UL;
    bit = 1;
}
else if (strcmp(s, "baz") == 0)
{
    bitmap = 0x00000003UL;
    bit = 2;
}
else if (strcmp(s, "qux") == 0)
{
    bitmap = 0x00000008UL;
    bit = 3;
}
else
{
    bitmap = 0;
    bit = -1;
}

I wersja zwięzła:

if      (strcmp(s, "foo") == 0) { bitmap = 0x00000001UL; bit = 0;  }
else if (strcmp(s, "bar") == 0) { bitmap = 0x00000002UL; bit = 1;  }
else if (strcmp(s, "baz") == 0) { bitmap = 0x00000003UL; bit = 2;  }
else if (strcmp(s, "qux") == 0) { bitmap = 0x00000008UL; bit = 3;  }
else                            { bitmap = 0;            bit = -1; }

Błędy są znacznie bardziej prawdopodobne, aby wskoczyć prosto w twarz.

Zastrzeżenie: ten przykład jest wymyślony, jak powiedziałem. Zapraszam do omówienia wykorzystania strcmp, magicznych liczb i czy podejście oparte na tabeli byłoby lepsze. ;)

#if 0 ... #endif jest dość powszechne w starszym kodzie C. Powodem jest to, że komentowanie komentarzami w stylu C /* .... */ nie działa, ponieważ komentarze nie zagnieżdżają się.

Chociaż jest to powszechne, powiedziałbym, że nie ma miejsca w nowoczesnym kodzie. Ludzie robili to w dawnych czasach, ponieważ ich edytory tekstu nie mogły automatycznie blokować dużych sekcji komentarzy. Co bardziej istotne, nie mieli odpowiedniej kontroli kodu źródłowego, tak jak my teraz. Nie ma usprawiedliwienia dla pozostawienia komentarza lub #ifdef ' D w kodzie produkcyjnym.