Spaziatura aggiuntiva prima di un commento incorporato [chiuso]

1

All'inizio della mia carriera mi è stato consigliato di aggiungere ulteriore spaziatura tra il codice sorgente e un commento in linea, in questo modo:

de_cologne = (i == 4711  # 1
              and j == 1799)  # 2

Nota i due spazi.

Presumibilmente, la ragione per fare ciò è distinguere gli operatori che usiamo per delimitare i commenti di altri operatori. Presumibilmente, questo potrebbe aiutare qualche povero lettore che è appena passato dalla lettura di un linguaggio di programmazione in cui l'operatore potrebbe significare qualcos'altro (in particolare per quanto riguarda l'aritmetica).

Nella mia esperienza, anche in Python dove la pratica è inscritta in PEP-8, la pratica è raramente rispettata. Posso ben immaginare che sia meno utile in alcuni domini rispetto ad altri.

Esiste una lingua particolare in cui questa è una buona pratica?

    
posta Caterpillar 13.09.2017 - 18:31
fonte

2 risposte

1

Lo stile è per lo più una questione di opinione. La scelta migliore è utilizzare la guida di stile ufficiale per la lingua preferita. Grazie ai commenti, sembra che PEP-8 sia una di queste guide che applica questa regola.

Si noti che PEP-8 non ti obbliga a inserire esattamente due spazi, ma almeno due spazi. Ciò significa che avresti potuto scrivere:

de_cologne = (i == 4711      # 0x1267
              and j == 1799)  # 0x707

Anche se in questo codice, vorrei semplicemente rendere i commenti inutili:

de_cologne = i == 0x1267 and j == 0x707

Suppongo che la persona che ti ha detto di farlo sia motivata dall'aspetto visivo, anche se potrebbero esserci modi migliori per separare chiaramente i commenti, ad esempio mettendoli su una linea separata in primo luogo.

In ogni caso, qualsiasi editor di testo decente ha evidenziazione della sintassi , che rende i commenti abbastanza distinti dal codice per richiedere ulteriori sforzi di formattazione.

Presumably, this might help some poor reader that just switched from a programming language in which the operator might mean something else

Se una persona passa da un altro linguaggio di programmazione, appartiene a questa persona per imparare la sintassi della nuova lingua. Non è tuo compito adattare il tuo codice alle persone che non conoscono la sintassi, e non sarai in grado di farlo comunque.

    
risposta data 13.09.2017 - 19:28
fonte
1

Supposedly, the reason for doing this is to distinguish operators that we use to delimit comments from other operators.

Se stai ricordando correttamente, questo è un motivo molto valido.

Alla fine della giornata, lo scopo di qualsiasi stile di codifica è quello di rendere codice errato sembra sbagliato , come fa notare. Non credo che la sua parte di PEP8 sia davvero importante, poiché lo stile di codifica giusto per un progetto è quello che meglio si adatta alle esigenze della squadra.

Mentre alcuni editori e langauge familiarità possono rendere i commenti in linea molto ovvi mentre si lavora sulla base di codice, ciò si basa sul presupposto che il vostro team lavorerà su questa base di codici e in questa lingua in modo perentorio. Probabilmente alla fine inizierai solo a eseguire una manutenzione minima su questa base di codice e a passare a una nuova lingua. In questo caso, potrebbe essere un po 'più semplice leggere questo codice con questa convenzione di stile.

Presumably, this might help some poor reader that just switched from a programming language in which the operator might mean something else (in particular with regards to arithmetic).

Quasi tutti i programmatori professionisti ad un certo punto della loro carriera si troveranno a dover leggere / modificare codice scritto in una lingua che non hanno familiarità con (sia perché è nuovo per loro, sia perché non lo hanno usato per così tanto tempo) .

    
risposta data 14.09.2017 - 03:32
fonte

Leggi altre domande sui tag