Python komentarze: # vs. strings

Question

odniesieniu do „standardowego” sposób umieścić komentarze wewnątrz kodu źródłowego Python:

def func(): 
    "Func doc" 
    ... <code> 
    'TODO: fix this' 
    #badFunc() 
    ... <more code> 

def func(): 
    "Func doc" 
    ... <code> 
    #TODO: fix this 
    #badFunc() 
    ... <more code> 

Wolę napisać ogólne uwagi jak ciągi zamiast poprzedzania # 's. Oficjalny przewodnik po stylu Pythona nie wspomina o używaniu ciągów znaków jako komentarzy (jeśli nie przegapiłem tego podczas czytania).

Podoba mi się to głównie dlatego, że myślę, że postać # wygląda brzydko z blokami komentarzy. O ile wiem, te struny nic nie robią.

Czy występują wady?

Answer 1

Nie używaj niepotrzebnych ciągów znaków (instrukcji no-op) jako komentarzy. Doctrings, np. pierwszy ciąg w module, klasie lub funkcji jest wyjątkowy i zdecydowanie zalecany.

Uwaga: dokumentacja to dokumentacja, a dokumentacja i komentarze to dwie różne rzeczy!

• Dokumentacja jest ważna, aby zrozumieć, , co robi kod.
• Komentarze wyjaśnić jak to robi kod.

Dokumentacja jest czytany przez ludzi, którzy użycie kod, komentarze ludzi, którzy chcą rozumieją swój kod, na przykład w celu jego utrzymania.

Korzystanie ciągi dla commentation ma następujące (potencjalnych) wady:

• To dezorientuje ludzi, którzy nie wiedzą, że ciąg nic nie robi.
• Komentarze i literały ciągów są podświetlane inaczej w edytorach kodu, dzięki czemu Twój styl może utrudnić odczytanie kodu.
• Może to efekt działania i/lub wykorzystanie pamięci (jeśli słowa nie są usuwane podczas kodu bajtowego kompilacji, usuwanie komentarzy odbywa się na poziomie skanera więc jej ostatecznie tańsze)

Najważniejszym dla programistów Pythona: Jest nie pyton:

Powinien istnieć jeden - a najlepiej tylko jeden - czysty sposób na zrobienie tego.

Trzymaj się standardów, używaj komentarzy.

Answer 2

Myślę, że tylko pierwszy literał ciągu w definicji (lub klasie) jest "specjalny", tj. Zostaje zapisany przez interpreter w zdefiniowanym obiekcie (lub klasie) docstring.

Wszelkie inne literały łańcuchowe umieszczane w kodzie będą w najgorszym przypadku oznaczać, że interpreter będzie budował wartość ciągu w czasie wykonywania, a następnie po prostu go wyrzuci. Oznacza to, że robienie "komentarzy" przez zaśmiecanie kodu za pomocą stałych łańcuchowych może kosztować, pod względem wydajności.

Oczywiście nie testowałem tego, a także nie znam interpretera Pythona na tyle dobrze, aby powiedzieć na pewno.

Answer 3

Wada polega oczywiście na tym, że ktoś czytający ją znajdzie, że łańcuchy kodu i ciągi komentarzy są przeplecione, co może być mylące.