Czy mogę używać znaku krzyżyka (#) do komentowania w PHP?


144

Nigdy, przenigdy nie widziałem pliku PHP używającego skrótów ( #) do komentowania. Ale dzisiaj zdałem sobie sprawę, że naprawdę mogę! Zakładam, że jest powód, dla którego wszyscy //zamiast tego używają , więc oto jestem.

Czy jest jakiś powód, oprócz osobistych preferencji, aby używać //zamiast #komentarzy?


16
To jest hash (lub funt lub kwadrat, w zależności od kraju, w którym się znajdujesz), a nie tag. Hashtag to sposób na kategoryzowanie treści na Twitterze.
Quentin

Możesz użyć odpowiednika zmiany znaczenia HTML & # 35; jeśli potrzebujesz symbolu # w swoim kodzie
dotoree

22
Myślałem, że ten #symbol nazywa się hash tag ... :( Nie ma powodu, aby tak mocno
odrzucać

3
Lubię używać #do komentarzy jednowierszowych, //do komentowania kodu i /* ... */bloków komentarzy
John Magnolia

Możliwy duplikat komentarzy PHP # vs //
nawfal

Odpowiedzi:


163

Odpowiedź na pytanie Czy jest jakaś różnica między używaniem znaków „#” i „//” dla komentarzy jednowierszowych w PHP? to nie .

Nie ma różnicy. Patrząc na parsującą część kodu źródłowego PHP, oba znaki „#” i „//” są obsługiwane przez ten sam kod i dlatego zachowują się dokładnie tak samo.


3
Zauważ, że N ++ (6.55) nie zawsze może #poprawnie składać komentarze. Zauważyłem, że w dużych plikach PHP: 2k linii lub więcej. Czasami zaczyna składać kod na wielu #.
KR

1
O wiele bardziej wolę #komentarze niż //te… ale zawsze się zastanawiałem, czy #jest to zgodne z PSR… Czy tak jest?
Stphane,

5
Hash jest pomocny przy opisywaniu tras, np. # /news (code here)zamiast // /news (code here). Jeśli chodzi o pliki 2k LoC, myślę, że są inne problemy niż to, który tag komentarza użyć :)
Juha Untinen

11

Dokumentacja PHP opisuje różne możliwości komentarzy. Zobacz http://www.php.net/manual/en/language.basic-syntax.comments.php

Ale nie mówi nic o różnicach między „//” i „#”. Więc nie powinno być różnicy technicznej. PHP używa składni C, więc myślę, że to jest powód, dla którego większość programistów używa komentarzy w stylu C „//”.


1
Lub używa składni Perla, w którym to przypadku pojawia się „#”. Perl pobiera składnię komentarzy z powłok unix-ey.
Gerard ONeill

7
<?php
    echo 'This is a test'; // This is a one-line C++ style comment
    /* This is a multi-line comment.
       Yet another line of comment. */
    echo 'This is yet another test.';
    echo 'One Final Test'; # This is a one-line shell-style comment
?>

RTM


// to komentarz w stylu C
Blue Water

6

Czy jest jakiś powód, poza osobistymi preferencjami, aby używać znaku // zamiast # do komentarzy?

Myślę, że to tylko osobiste preferencje. Nie ma różnicy między //i #. Osobiście używam #do komentowania jednowierszowego, //do komentowania kodu i /** */do komentowania blokowego.

<?php
    # This is a one-line comment
    echo 'This is a test';

    // echo 'This is yet another test'; // commenting code

    /** 
     * This is a block comment
     * with multi-lines 
     */
    echo 'One final test';
?>

Lubię używać //do zwykłych komentarzy do kodu, ponieważ większość ludzi używa tego podczas komentowania kodu. Używam #komentarzy, które mają opisywać, a nie być kodem, który jest zakomentowany. Unikanie /**/jednej linijki zmniejsza konflikty otwierania / zamykania, gdy próbujesz użyć /**/w kodzie, który ma `/ ** / w tym kodzie ... kończy się przedwczesnym zamknięciem. i to jest złe.
ahnbizcad

5

Można by pomyśleć, że #forma komentowania ma przede wszystkim na celu stworzenie skryptu powłoki przy użyciu znanej notacji „shebang” (#!). W poniższym skrypcie PHP powinno zignorować pierwszą linię, ponieważ jest to również komentarz. Przykład:

#!/usr/bin/php
<?php

echo "Hello PHP\n";

Jeśli przechowujesz go w pliku wykonywalnym, możesz uruchomić go z takiego terminala

./hello

Wynik jest

Hello PHP

Jednak to rozumowanie jest błędne, jak pokazuje następujący kontrprzykład:

#!/usr/bin/php
#A
<?php

#B
echo "Hello PHP\n";

Pierwsza linia (linia shebang) jest specjalnie ignorowana przez tłumacza. Wiersz komentarza przed tagiem PHP jest wywoływany na standardowe wyjście, ponieważ nie znajduje się wewnątrz tagu PHP. Komentarz po otwierającym tagu PHP jest interpretowany jako kod PHP, ale jest ignorowany, ponieważ jest komentarzem.

Wynik poprawionej wersji to

#A
Hello PHP

13
W rzeczywistości shebang jest poza kodem PHP, więc absolutnie nie jest komentarzem do PHP . Spróbuj usunąć !i uruchom plik z phpwiersza poleceń: wypisze "# / usr / bin / php". Powodem, dla którego shebang jest ignorowany jest to, że PHP rozpoznaje linie shebang na samym początku pliku i ignoruje je.
Ninj

Używając php7.4, oba komentarze są powtarzane. Więc pasmo nie jest (lub już nie jest) ignorowane.
Chargnn

0

Jeśli ustalisz jakieś zestawy reguł w swoim zespole / projekcie ... 2 typy komentarzy mogą być użyte do nakreślenia celu komentowanego kodu.

Na przykład lubię używać #do wyciszania / wyłączania ustawień konfiguracji, podfunkcji i ogólnie fragmentu kodu, który jest przydatny lub ważny, ale jest aktualnie wyłączony.


Lubię robić coś przeciwnego, ale zasadniczo to samo w duchu. użyj jednego do komentarzy do kodu, a drugiego do komentarzy opisu.
ahnbizcad

@ahnbizcad lepiej jest używać bloków komentarzy do opisu / ** * * /
d.raev

czemu. ---- / - / - / - / -
ahnbizcad

0

Nie ma na to oficjalnego PSR.

Jednak w całym przykładowym kodzie PSR używają one //komentarzy wbudowanych.

Istnieje propozycja rozszerzenia PSR-2, która ma na celu jej standaryzację, ale nie jest oficjalna: https://github.com/php-fig-rectified/fig-rectified-standards/blob/master/PSR-2-R-coding- style-guide-additions.md # commenting-code

//jest częściej używany w kulturze PHP, ale można go również używać #. Osobiście podoba mi się to, że jest krótszy i oszczędza bajty. To osobisty gust i stronniczość, nie ma na to właściwej odpowiedzi, dopóki, oczywiście, nie stanie się standardem, za czym powinniśmy starać się jak najbardziej podążać.


Problem ze standardami w dziedzinie informatyki polega na tym, że aby stworzyć standard, trzeba mieć najlepszą opcję, aw informatyce nie ma czegoś takiego jak najlepsza opcja. Są tylko złe opcje i lepsze opcje. Ale „najlepsza opcja” nie istnieje.
Blue Water

0

Tak, jednak istnieją różnice między platformami.

Cały czas używam # do komentowania w PHP, ale zauważyłem różnicę w przyjęciu.

Na klawiaturze systemu Windows klawisz # jest łatwy w użyciu. Na klawiaturze Maca najczęściej nie ma klawisza #.

Tak więc dla użytkowników komputerów Mac, [Alt] + [3] lub [⌥] + [3] jest trudniejsze do wpisania niż //, więc // stało się międzyplatformowym sposobem wyświetlania kodu z komentarzami.

To jest moja obserwacja.


0

Z https://php.net/manual/en/migration53.deprecated.php

„Przestarzałe funkcje w PHP 5.3.x ... Komentarze zaczynające się od '#' są teraz nieaktualne w plikach .INI.”

Masz to. Hash „#” wydaje się domyślnie pozostawać jako opcja komentarza, ponieważ nie jest przestarzała. Planuję go użyć do rozróżnienia różnych warstw zagnieżdżonych instrukcji if / else i zaznaczenia ich nawiasów zamykających lub do odróżnienia komentarzy do kodu od zakomentowanego kodu, jak sugerowali inni w powiązanych postach. (Uwaga: link był ważny / działał od 23.04.19, chociaż kto wie, czy nadal będzie działał, gdy to czytasz).


0

Czy jest jakiś powód, poza osobistymi preferencjami, aby używać znaku // zamiast # do komentarzy?

Przyszedłem tutaj po odpowiedź i dobrze jest wiedzieć, że NIE ma różnicy w kodzie.

Jednak z punktu widzenia preferencji można by argumentować, że wolisz spójność komentarzy „shell-> perl-> php” zamiast sposobu „c-> php”.

Ponieważ podszedłem do php jak do perla dla biednych ludzi, użyłem # .., a potem zobaczyłem kod kogoś innego i przeszedłem prosto do SO. ;)


-8

Komentarze z "#" są przestarzałe w PHP 5.3. Dlatego zawsze używaj // lub / ... /


21
Są przestarzałe tylko w plikach INI .
DisgruntledGoat

@DisgruntledGoat Jakieś odniesienia do oficjalnej dokumentacji?
Wilt

1
Prosto z php.net: Komentarze zaczynające się od „#” są teraz przestarzałe w plikach .INI.
Wilt

4
Andre, może czas usunąć tę odpowiedź.
Jose Manuel Abarca Rodríguez

1
mniej badań! sprawi, że stracisz :) ale to też pomogło mi wiedzieć, że # jest przestarzałe w plikach INI
Abdul Manan,
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.