Jak rozwiązać problem zagnieżdżonych komentarzy

23

Pojawia się w nie tylko jednym języku, że komentarzy nie można zagnieździć. Czy masz dobre rozwiązanie tego problemu? Jednym z obejść w C / C ++ i Javie jest używanie tylko komentarza jednowierszowego, ale niemożliwe staje się wówczas komentowanie większego bloku. Mam do czynienia z czymś takim:

</li><!--
                <li><!-- Save -->

Więc muszę ręcznie przejść i edytować komentarze. Czy możesz doradzić, jak powinniśmy sobie z tym poradzić, w wielu językach? Nie jestem pewien, ale może python ma na to rozwiązanie, '''które może zawierać #komentarz w pythonie? `

Niklas
źródło
4
Myślę, że tylko redaktorzy mogą ci w tym pomóc. IDLE zablokuje jednak dla ciebie komentarz na Python IIRC.
Erik Reppen
7
Python nie ma komentarzy blokowych . '''I """literały ciągów znaków . Zdarza się, że interpreter oceni je podczas kompilacji (do kodu bajtowego) i rozpozna literały łańcuchowe jako brak operacji (dlatego nie spowalniają czasu wykonywania / ładowania kodu bajtowego). Ciągi znaków, tj. Literały łańcuchowe tuż za a, defale przed ciałem, nie są usuwane, ponieważ interpreter zakłada, że ​​zapewnia dokumentację dla funkcji.
Bakuriu
7
W C / C ++, jeśli chcesz usunąć duże sekcje, użyj #if 0<code> #endif. Więc to nie jest tak naprawdę problem. Używanie do tego komentarzy jest złym narzędziem.
Martin York
1
Dawno temu przełączyłem się na używanie tylko komentarzy liniowych (o ile nie jestem zmuszony, np. Javadoc). Oczywiście potrzebujesz obsługi edytora (lub przynajmniej trybu kolumnowego).
ziggystar

Odpowiedzi:

46

Najlepszym rozwiązaniem jest oczywiście nie zagnieżdżanie komentarzy. Komentarze zagnieżdżone są zwykle oznaką niewłaściwego używania komentarzy. Najczęstszym przykładem jest kod z komentarzem, który zawiera same komentarze, a poprawką jest usunięcie kodu zamiast komentowania go.

To powiedziawszy, wiele języków programowania ma więcej niż jeden typ składni komentarzy, i możesz użyć tego faktu, aby zagnieździć co najmniej jeden poziom głębokości. Na przykład w Javie:

/* This is commented out!
Foo.bar.baz();
// And now for something completely different...
Quux.runWith(theMoney);
*/

Ponadto w wielu językach co najmniej jeden rodzaj komentarza można zagnieździć; w językach podobnych do C komentarze linii wewnątrz komentarzy linii są ignorowane:

// some_commented_out(code);
// // This is a comment inside the comment!
// // Still inside the nested comment.
// some_more_code_in(outer_comment);

Większość IDE obsługuje komentowanie całych bloków kodu za pomocą komentarzy liniowych w jednej akcji i poprawnie obsługuje ten rodzaj stylu komentowania. Ten sam przykład w Pythonie:

# some_commented_out(code)
# # This is a comment inside the comment!
# # Still inside the nested comment.
# some_more_code_in(outer_comment)

Często standardy kodowania dla konkretnego projektu mają reguły dotyczące tego, który styl komentarza ma być używany; powszechną konwencją jest stosowanie komentarzy blokowych ( /* */) do dokumentacji metod i klas oraz komentarzy wbudowanych ( //) do uwag wewnątrz treści metod i takich, np .:

/**
 * Helper class to store Foo objects inside a bar.
 */
public class Foobar {
    /**
     * Stores a Foo in this Foobar's bar, unless the bar already contains
     * an equivalent Foo.
     * Returns the number of Foos added (always 0 or 1).
     */
    public int storeFoo(Foo foo) {
        // Don't add a foo we already have!
        if (this.bar.contains(foo)) {
            return 0;
        }
        // OK, we don't have this foo yet, so we'll add it.
        this.bar.append(foo);
        return 1;
    }
}

Przy takim stylu jest mało prawdopodobne, że kiedykolwiek będziesz musiał zagnieżdżać /* */komentarze (jeśli musisz tymczasowo wyłączyć całe metody lub klasy, zmiana ich nazwy działa równie dobrze, jeśli nie lepiej); i //komentarze zrobić gniazdo, przynajmniej z niewielką pomocą z Twojego IDE.

Wreszcie, aby wyłączyć kod, masz inne opcje w wielu językach programowania; na przykład w C można wykorzystać preprocesor:

this_is(activated);
#if 0
this_is(!activated);
/* Comments inside this block don't really nest, they are simply removed
   along with the rest of the block! */
#endif

W językach dynamicznych często można ifzamiast tego użyć zwykłych instrukcji:

<?php

if (0) {
   // This should never run... 
   some_stuff_that_should_never_run();
}

Jednak w przeciwieństwie do przykładu CPP ta strategia wymaga, aby plik źródłowy jako całość był poprawny pod względem składniowym, więc nie jest on tak elastyczny.

I wreszcie, istnieją przynajmniej niektóre języki, które pozwalają na zagnieżdżanie komentarzy. Jeśli jesteś zainteresowany, wikipedia ma fajną tabelę porównawczą .

tdammers
źródło
2
czy jakiś wariant SQL pozwala na zagnieżdżone komentarze?
Xavier Combelle
3
+1 za// And now for something completely different...
Vorac
1
@Vorac: Cieszę się, że podoba Ci się odniesienie: D
tdammers
18

C i C ++ mają zagnieżdżone komentarze blokowe:

#if 0
#endif

Wielu redaktorów wyróżniających traktuje to jako komentarz, a wielu innych przynajmniej podświetli to jak każdy inny warunkowo wyłączony kod.

W wielu innych językach musisz polegać na wsparciu edytora. W przypadku języków, które mają tylko komentarze liniowe (perl, python, ruby, shell ...), dość łatwo jest wstawić znak komentarza do wszystkich linii w zakresie, więc większość redaktorów może to zrobić. Nadal możesz powiedzieć, jakie były komentarze, zanim skomentujesz cały blok, ponieważ znak komentarza jest podwojony - robienie tego jest po prostu zaletą.

XML i SGML to chyba największy problem, definicja komentarzy jest po prostu głupia. Komentarze byłyby trywialne do zagnieżdżenia, ale nie tylko nie, to jest całkowicie zabronione mieć --komentarz wewnętrzny. Niestety nie wiem, którzy redaktorzy mają dobre wsparcie dla komentowania w SGML / XML.

Jan Hudec
źródło
2
Nigdy nie myślałem o użyciu tych dyrektyw preprocesora jako rzeczywistych komentarzy. Interesujące, również dla C #, ale w takim przypadku trzeba by zrobić coś takiego, #if _co również działa dobrze i zostaje wyszarzone w moim VS z Re #. Dobra wskazówka!
Grimace of Despair
2

Chociaż nie jest to ogólne rozwiązanie i na pewno nie jest idealne, jednym ze sposobów rozwiązania tego konkretnego problemu jest użycie języka przetwarzania szablonów po stronie serwera do blokowania komentarzy do elementów komentarzy kodu zagnieżdżonego. Pozostawia to treść zasadniczo nienaruszoną, ale uniemożliwia przesłanie jej do przeglądarki klienta.

To niewiele pomaga, jeśli w innym przypadku plik jest prostą i czystą zawartością, która nie wymaga żadnego przetwarzania po stronie serwera. W takim przypadku i bardziej ogólnym przypadku zagnieżdżonych komentarzy zapytaj, dlaczego chcesz to zrobić. W większości tych przypadków najlepszym sposobem na poradzenie sobie z tym problemem może być nie zajmowanie się wszystkim. Innymi słowy, jeśli chcesz wyeliminować sekcję, usuń ją i pozwól kontroli wersji zapamiętać różnice, jeśli ta sekcja jako artefakt kiedykolwiek będzie musiała zostać wskrzeszona.

JustinC
źródło
0

W przypadku HTML / XML możesz użyć nieistniejącej instrukcji przetwarzania: zobacz moją odpowiedź na SO

<?ignore
  <band height="20">
    <staticText>
      <reportElement x="180" y="0" width="200" height="20"/>
      <text><![CDATA[Hello World!]]></text>
    </staticText>
  </band>
?>
</detail>
Kasper van den Berg
źródło
0

Swift obsługuje zagnieżdżone komentarze, więc „pojawia się w nie tylko jednym języku, że komentarzy nie można zagnieździć” nie jest już prawdziwym stwierdzeniem. Jeśli nie jesteś zadowolony z braku obsługi zagnieżdżonych komentarzy w twoim języku programowania, sugeruję wypróbowanie Swift.

/* This is the start of the first multiline comment.
 /* This is the second, nested multiline comment. */
 This is the end of the first multiline comment. */

Szybki język programowania: podstawy

złość
źródło
0

Język programowania D ma wbudowane komentarze:

/+ This is a nested comment 
  /+ This is part of that a comment +/
  /* So is this */
+/
/+ /* This is another nested comment */ +/
/* /* This is not a nested comment */

Innymi słowy, /+oraz +/komentarze gniazdo.

noɥʇʎԀʎzɐɹƆ
źródło