Per pura curiosità, ho iniziato a chiedermi se un linguaggio che non consente commenti possa produrre codice più leggibile, in quanto si sarebbe costretti a scrivere un codice di commento automatico.
Poi di nuovo, potresti scrivere codice altrettanto brutto di prima perché semplicemente non ti interessa. Ma qual è la tua opinione?
Penso che i programmatori troverebbero un altro modo per aggiungere commenti ...
string aComment = "This is a kludge.";
Non penso sia così semplice:
anche in un codice ben scritto e autodocumentato, ci sono situazioni legittime in cui dovresti scrivere commenti.
Supponiamo che tu sia un programmatore perfetto (che non lo sei, ma supponiamo) ...
Ci sono molti effetti non ovvi che possono accadere nel codice quando ti interfaccia con cose che non hai scritto. Ad esempio, ci possono essere difetti di progettazione nella libreria di qualcun altro o (se sei uno sviluppatore del kernel) nell'hardware di qualcun altro. Avere commenti per spiegare perché hai usato particolari kludge in un posto particolare può essere essenziale per capire il codice, e assicurarti che il kludge non sia rimosso (rompendo le cose).
È difficile per me avvolgere la mia mente sull'idea che rimuovere le opzioni da una lingua possa in qualche modo rendere i programmi scritti in questa lingua meglio. I commenti non sono obbligatori e la scrittura del codice di autocertificazione non è altrettanto buona.
Non ci sono sostituti per buone pratiche di sviluppo.
In teoria, COBOL è stato originariamente progettato in modo tale che si intendesse la documentazione di autodidatta che anche i non gli sviluppatori (cioè i supervisori) potevano rivedere il codice che era stato scritto e determinare cosa stava succedendo. Tuttavia, in pratica, poiché un programma diventa più complesso, è difficile capire tutto ciò che accade solo attraverso il codice.
Mentre rimuovere i commenti potrebbe costringere alcuni sviluppatori a scrivere codice che è meglio all'autodocumentazione, ci sono ancora sviluppatori che scrivono codice scarsamente documentato (ad esempio nomi variabili di a , b , c , ecc.) ed è proprio da quelle abitudini che le persone hanno bisogno di essere addestrate. In questi casi, la rimozione dei commenti non influirebbe su quegli sviluppatori e potrebbe ostacolare gli sforzi di altri sviluppatori per spiegare pezzi complessi di codice.
Ogni programma viene scritto per implementare requisiti funzionali al di fuori del programma, sia che siano scritti o solo in testa a qualcuno.
Penso che la funzione più essenziale dei commenti sia stabilire una mappatura tra i requisiti e il codice. Il motivo per cui è necessaria la mappatura è consentire modifiche incrementali. Quando si verifica una modifica ai requisiti, è necessario apportare le modifiche corrispondenti al codice, se il codice deve rimanere una soluzione ai requisiti. I commenti servono come guida per le modifiche.
Se la lingua è un linguaggio di dominio specifico (DSL) ideale perfettamente adattato al problema da risolvere, allora la mappatura dovrebbe essere un semplice isomorfismo, ei commenti non sarebbero necessari. Il codice sorgente dovrebbe semplicemente indicare il problema, e nient'altro avrebbe bisogno di essere detto. La soluzione del problema verrebbe sepolta nell'implementazione del linguaggio.
Poiché le lingue in cui lavoriamo non sono tali DSL, e rimarranno tali per qualche tempo, abbiamo ancora bisogno di commenti . È una questione di laurea. A volte il problema è una buona corrispondenza con la lingua a portata di mano, ma di solito no.
Lavoro da qualche parte che non consente commenti in linea (ad esempio, puoi avere solo commenti nella parte superiore delle funzioni). No, non rende il codice più facile da leggere. Rende peggio gli ordini di grandezza.
Evito tutti i commenti in-code (inline o stream) a favore di docblock + varables significativi + < a href="http://www.codinghorror.com/blog/2008/07/spartan-programming.html"> programmazione spartana , e funziona.
E sì, so che i docblock sono tecnicamente commenti, tuttavia sono in realtà complementari al codice, non invadenti e "standardizzati" ... tutto ciò che un commento comune non è.
Quello che penso potrebbe funzionare come sostituto dei commenti: un linguaggio docblock standardizzato / sintassi / idioma, qualcosa come annotazioni in java.
Non solo non influenzerebbe la qualità - come altri hanno osservato, sarebbe davvero molto fastidioso.
Sono sicuro che molti di noi hanno fatto qualcosa del genere di tanto in tanto:
foreach ( myObject obj in SomeList )
{
Debug.Writeline( obj.Name );
// for some reason this isn't working
// obj.SetArielPotency( setting );
// obj.DoSomeProcess();
}
Quanto sarebbe irritante se non riuscissi a commentare alcune righe di codice per capire da dove viene questo bug?
Indipendentemente dai commenti su come funziona il codice, semplici cose pratiche come questa o cadere in una comoda nota di TODO sono cose che rendono più facile risolvere problemi minori e ricordare cosa stavamo facendo quando abbiamo iniziato a scrivere il codice.
Anche se sono d'accordo con le altre risposte che anche il codice di auto-documentazione ha bisogno di commenti, è rilevante solo per le lingue correnti.
Penso che la vera domanda sia, "È possibile progettare un nuovo linguaggio di programmazione che non abbia bisogno di commenti?" Dovrebbe essere un livello piuttosto alto con una grande quantità di astrazione. Ogni istruzione e funzione sarebbero forzate ad essere leggibili tramite la sintassi del linguaggio.
I programmatori non disciplinati scriveranno codice non valido, indipendentemente dalla lingua.
Intrigante che Python, che ha solo un privato per convenzione (prefisso _), non fa alcuno sforzo per controllare questo, e viene scritto ancora molto codice.
Rant: A volte penso che i langugages più permissivi costringano più persone a imparare a codificare correttamente, piuttosto che al contrario (cioè, l'unica a senso unico di Java e dannata se tu vuoi pensare a funzioni come oggetti di prima classe).
Indovino: probabilmente no. Perché? Perché dovresti codificare "perché" come formalismo nella lingua e perché "perché", sia codificato in linguaggio o commenti in linguaggio è comunque sottoutilizzato dai programmatori.
Il codice può certamente essere auto-commentante nello spiegare cosa sta facendo, ma non è sempre possibile che il codice spieghi perché lo sta facendo. È qui che i commenti sono più necessari.
Se, per esempio, è necessaria una sezione di codice per conformarsi a un regolamento specifico, come lo spieghi senza un commento? Se l'algoritmo usato da un particolare pezzo di codice è descritto in un documento scritto nel 1998 da M. Matsumoto e T. Nishimura, come lo spieghi senza un commento? Se un algoritmo non fornisce esattamente la funzionalità ottimale ma fa un compromesso giustificato molto specifico che potrebbe causare problemi futuri se viene modificato un altro codice, come lo spieghi senza un commento?
Cosa succede se una sezione del codice è stata verificata da un revisore indipendente, quindi non può essere modificata senza invalidare tale verifica e il codice viene utilizzato per creare un prodotto la cui conformità con tale verifica è richiesta dai clienti. Come si indica che senza un commento?
I commenti sono come un sommario di un libro. Certo, puoi capire tutto leggendo il codice, ma perché mai vuoi leggere un'intera pagina quando potrebbe essere riassunta in una riga commentata?
Ho sempre pensato che sarebbe stato carino avere un commento di una sola parola in modo che se avessi prefisso una parola con un simbolo (diciamo i due punti), quella parola sarebbe stata ignorata. In questo modo, si potrebbe dire una lisc che ha permesso solo commenti di una sola parola all'interno di un'espressione s. Ad esempio, puoi girare questo:
(if (= x y)
x
y)
... in questo:
(if (= x y)
:then x
:else y)
Se è assolutamente necessario, è possibile associare più commenti di una sola parola per formare un commento in linea:
(if x :Remember, :x :could :be :nil!
...)
Certo, questo è un dolore da digitare. In effetti, questo è il punto. Ti incoraggia a usare i commenti in linea con parsimonia e tenerli corti e al punto. Ma ho la sensazione che avrei avuto difficoltà a convincere qualcuno a usare la lingua.
Questo è doppio o niente. Alcuni programmatori non fanno nulla per rendere leggibile il codice. Non consentire i commenti rafforzerà questo. Alcuni programmatori scrivono buoni commenti, anche se sarebbero ancora meglio se fossero il refactoring del codice piuttosto che i commenti: rimuovere i commenti potrebbe costringerli a fare il refactoring migliore.
Ragioni per cui questa è una buona idea: - Nessuno
Motivi per cui questa è una cattiva idea: - Ci sono molti più programmatori atroci di programmatori bravi ma non grandi - Ci dovrebbero essere quasi sempre alcuni commenti per strani trucchi, riassunti, ecc - Anche se non rispondi ai commenti, probabilmente utilizzerai i commenti come un palcoscenico sulla strada: aggiungi un commento quando scrivi qualcosa, quindi torna indietro e rifattalo. Ma non puoi sempre farlo subito perché stai ancora imparando. - Incoraggerà le persone a lavorare attorno ad esso - Chi lo userebbe? Persone che scrivono codice illeggibile e vogliono una scusa (cattiva) e persone che sono già innamorate dell'idea (che può semplicemente "non scrivere commenti" per cominciare). Se questo è quello che vuoi, basta scrivere uno standard di codice che mostri come vuoi che le persone lo facciano.
Motivi in cui ciò potrebbe essere rilevante - Dove potrebbe essere utile è come parte di un sistema per rendere "non commentare" meglio, ad es. un linguaggio o IDE che ha un buon supporto per qualcosa di meglio dei commenti e come parte del suo tono, evita i commenti. Non so come funzionerebbe, ma è un buon punto che vale la pena almeno pensare.
Leggi altre domande sui tag comments