Jednej rzeczy nikt jeszcze nie wspomniał, więc wspomnę o tym: chęć zagnieżdżania komentarzy często wskazuje, że programista robi to źle.
Po pierwsze, zgódźmy się, że jedyny czas, w którym „zagnieżdżanie” lub „brak zagnieżdżania” jest widoczny dla programisty, to kiedy programista pisze coś strukturalnie takiego:
do_something();
/* comment /* nested comment */ more comment */
do_something_else();
Kiedy taka rzecz pojawia się w praktyce? Z pewnością programista nie będzie pisał zagnieżdżonych komentarzy, które dosłownie wyglądają jak powyższy fragment! Nie, w praktyce, gdy zagnieżdżamy komentarze (lub chcielibyśmy je zagnieździć), to dlatego, że chcemy napisać coś takiego:
do_something(); /* do a thing */
/* [ajo] 2017-12-03 this turned out to be unnecessary
do_something_else(); /* do another thing */
*/
A to jest ZŁE. To nie jest wzór, który my (jako projektanci języków) chcemy zachęcać! Poprawny sposób pisać powyższy fragment brzmi:
do_something(); /* do a thing */
Ten „zły” kod, ten fałszywy start lub cokolwiek to było, nie należy do bazy kodów. W najlepszym wypadku należy do historii kontroli źródła. Idealnie byłoby, gdybyś nigdy nie napisał niewłaściwego kodu na początku, prawda? A jeśli niewłaściwy kod służył tam celowi, ostrzegając opiekunów, aby nie przywracali go z jakiegoś powodu, to prawdopodobnie jest to zadanie dla dobrze napisanego i celowego komentarza do kodu. Próba wyrażenia „nie rób X” przez pozostawienie starego kodu X, ale skomentowanego, nie jest najbardziej czytelnym ani skutecznym sposobem powstrzymania ludzi przed robieniem X.
Wszystko sprowadza się do prostej zasady, którą mogłeś usłyszeć wcześniej: nie komentuj kodu. (Do wyboru w tym zdaniu zamieni się na wiele z opinii w umowie ).
Zanim zapytasz: tak, języki, takie jak C, C # i C ++ już dać programiście innego narzędzia do „komentarz out” dużych bloków kodu: #if 0. Ale to tylko szczególne zastosowanie preprocesora C, który sam w sobie jest dużym i użytecznym narzędziem. W rzeczywistości język byłby wyjątkowo trudny i wymagałby specjalnego uwzględnienia kompilacji warunkowej z obsługą, #ifale jeszcze nie#if 0 .
Ustaliliśmy, że zagnieżdżone komentarze są istotne tylko wtedy, gdy programista komentuje kod; i ustaliliśmy (w drodze konsensusu wielu doświadczonych programistów), że komentowanie kodu jest złą rzeczą.
Aby ukończyć sylogizm, musimy zaakceptować fakt, że projektanci języków są zainteresowani promocją dobrych rzeczy i zniechęcaniem do złych rzeczy (zakładając, że wszystko inne jest równe).
W przypadku komentarzy zagnieżdżonych wszystko inne jest równe - możesz bezpiecznie zignorować nisko głosowane odpowiedzi, które twierdzą, że parsowanie zagnieżdżone /*byłoby w jakiś sposób „trudne” dla parsera. (Zagnieżdżone /*nie są trudniejsze niż zagnieżdżone (, z czym już musi sobie poradzić prawie każdy parser na świecie).
Tak więc, wszystkie pozostałe były równe, należy projektant język sprawiają, że jest łatwy do komentarzy gniazdo (czyli do ustosunkowania się kod) lub trudne? Przypomnij sobie, że komentowanie kodu jest złą rzeczą.
CO BYŁO DO OKAZANIA
Notatka. Zauważ, że jeśli nie zezwolisz na zagnieżdżone komentarze, to
hello /* foo*/bar.txt */ world
jest mylącym „komentarzem” - jest równoważny z
hello bar.txt */ world
(co jest prawdopodobnie błędem składni). Ale jeśli zrobić pozwalają zagnieżdżone komentarze, a następnie
hello /* foo/*.txt */ world
jest mylącym „komentarzem” - jest równoważny z
hello
ale pozostawia komentarz otwarty aż do końca pliku (co znowu prawie na pewno jest błędem składniowym). Tak więc żaden sposób nie jest szczególnie mniej podatny na niezamierzone błędy składniowe. Jedyna różnica polega na tym, jak radzą sobie z umyślnym antypatternem skomentowanego kodu.