La sintassi per disabilitare il codice dovrebbe differire da quella dei normali commenti?

Question

La sintassi per disabilitare il codice dovrebbe differire da quella dei normali commenti?

#1 da (18 voti)
#2 da (5 voti)
#3 da (4 voti)
#4 da (1 voti)

8

Per diversi motivi durante lo sviluppo, a volte commento il codice. Dato che sono caotico e talvolta di fretta, alcuni di questi lo rendono al controllo del codice sorgente.

Uso anche commenti per chiarire blocchi di codice.

Ad esempio:

MyClass MyFunction()
{
    (...)
    // return null; // TODO: dummy for now
    return obj;
}

Anche se "funziona" e molte persone lo fanno in questo modo, mi infastidisce il fatto che non è possibile distinguere automaticamente il codice commentato dai commenti "reali" che chiariscono il codice:

aggiunge rumore durante il tentativo di leggere il codice
non puoi cercare il codice commentato per esempio un hook on-commit nel controllo del codice sorgente.

Alcune lingue supportano più stili di commento a riga singola - per esempio in PHP puoi usare // o # per un commento a riga singola - e gli sviluppatori possono concordare l'utilizzo di uno di questi per il codice commentato:

# return null; // TODO: dummy for now
return obj;

Altre lingue, come C # che uso oggi, hanno uno stile per i commenti a riga singola (giusto? vorrei sbagliarmi). Ho anche visto esempi di codice "commenting-out" usando le direttive del compilatore, che è ottimo per grandi blocchi di codice, ma un po 'eccessivo per le singole linee poiché sono necessarie due nuove linee per la direttiva:

#if compile_commented_out
    return null; // TODO: dummy for now
#endif
return obj;

Quindi, dato che il codice di commento si verifica in ogni (?) lingua, il "codice disabilitato" non dovrebbe avere la propria sintassi nelle specifiche del linguaggio? I pro (separazione dei commenti / codice disabilitato, editor / controllo del codice sorgente che agisce su di essi) sono abbastanza buoni e gli aspetti negativi ("non dovrebbero fare commenti in ogni caso", non una parte funzionale di un linguaggio, potenziale ritardo dell'IDE (grazie Thomas )) vale la pena sacrificare?

Modifica

Mi rendo conto che l'esempio che ho usato è sciocco; il codice fittizio potrebbe essere rimosso facilmente in quanto sostituito dal codice effettivo.

syntax comments

posta deltreme 22.08.2011 - 13:06

fonte

4 risposte

5

For several reasons during development I sometimes comment out code. As I am chaotic and sometimes in a hurry, some of these make it to source control.

Penso che questa sia la radice del problema. Essere caotici e precipitosi sta solo introducendo problemi. Capire perché il tuo sviluppo si sta affrettando e non è ben controllato dovrebbe essere il primo passo, non cercare di trovare il codice commentato.

So as commenting-out code happens in every(?) language, shouldn't "disabled code" get its own syntax in language specifications? Are the pro's (separation of comments / disabled code, editors / source control acting on them) good enough and the cons ("shouldn't do commenting-out anyway", not a functional part of a language) worth sacrificing?

Io non la penso così Il codice commentato è una cattiva pratica e non credo che le lingue dovrebbero incoraggiare qualcuno a usarlo. Sì, la gente lo fa e l'ho visto, ma mi rifiuto di controllare il mio codice che viene commentato. Dare alle persone la possibilità di gestire facilmente il vecchio codice non utilizzato va oltre lo scopo di un linguaggio ed è qualcosa che appartiene al regno del controllo della versione.

Sono anche preoccupato per le limitazioni tecniche. Affinché questo funzioni, è necessario analizzare i commenti e determinare se vengono commentati come sorgente o testo o aggiungere un nuovo token alla lingua. A seconda dell'attuale complessità della lingua, non sono del tutto sicuro di quale impatto ciò avrebbe sulla compilazione (identificando se una riga è o non è un codice valido da compilare). Inoltre, le persone si aspetterebbero che gli IDE possano gestirli in tempo reale (esiste una relazione tra la complessità della sintassi di un linguaggio e la reattività degli IDE per trovare ed evidenziare vari costrutti ed errori).

risposta data 22.08.2011 - 14:06

fonte

4

Anche se esiste una sola sintassi di commento nella lingua che stai utilizzando, puoi comunque aggiungere il tuo gusto personale, ho lavorato a progetti in cui // indicava una linea disabilitata e // - indicava un commento. Non è bello come averlo integrato, ma la maggior parte degli IDE non sanno che hai usato le diverse sintassi per scopi diversi, quindi a volte il vecchio modo di guardare gli occhi per vedere la differenza funziona meglio.

risposta data 22.08.2011 - 13:27

fonte

1

In opposizione alle risposte, risponderò con un "SÌ, dovrebbe esserci una sintassi diversa!"

Vorrei sfidare qualsiasi sviluppatore a dire che ha attraversato anche un giorno di programmazione senza commentare il codice. Fare ciò non significa che non si conosca il controllo del codice sorgente o che sia pigro. Anche se Thomas Owens dice nella sua risposta dissenziente, " Tranne quando sono in un codice / test / codice / test ... mode, non commento codice inutilizzato. "

Quanto del tuo tempo è trascorso in modalità codice / test / codice / test? Per me è almeno il 90% del lavoro! Al momento sto convertendo un grande progetto OSX in iOS, e il primo passo è stato quello di disabilitare tutto il codice che si stava rompendo fino a quando ho avuto uno stub che ha funzionato. Per le prossime settimane sarò lentamente a disagio e correggerò il codice man mano che lo faccio funzionare.

Ci sono anche molti altri casi. Che cosa succede quando utilizzi un codice di esempio in cui spesso trovi indicazioni come "Elimina commento per Windows" o "Decommenta questa riga per le app per soli iPhone"?

Sì, userò sempre il controllo del codice sorgente. Ma anche SÌ, mi piacerebbe che ci fosse un modo per distinguere il codice disabilitato dai commenti reali.

In sintesi: qualsiasi programmatore che dice di non usare commenti per disabilitare il codice sta mentendo. C'è molto di più nella codifica dei file lucidati che si impegnano in HEAD. Esistono molti motivi validi per il codice disabilitato.

Sì, sarebbe bello se ci fosse una sintassi (o almeno una convenzione) per distinguere i commenti veri dal codice disabilitato.

risposta data 17.10.2013 - 20:51

fonte

Leggi altre domande sui tag syntax comments

Principi di programmazione per quanto riguarda l'efficienza del software (computazionale) e l'uso di variabili Un nuovo CAPTCHA che usa le frasi?

score 18 · Accepted Answer

Prima di tutto, nel tuo esempio ci sono i commenti di "TODO". Questi tipi di commenti sono speciali in un modo perché vengono rilevati dagli IDE (almeno Eclipse e Visual Studio) come marker per "attività". Ma sono sicuro che lo sai dato che usi thme, e suppongo che non ti stia riferendo a loro quando usi il termine "codice disabilitato".

Per quanto riguarda il codice disabilitato, la mia opinione è che inquini il codice. Uso un altro meccanismo per tenere traccia di ciò che c'era prima: il repository sorgente . Tranne quando sono in una modalità di codice / test / codice / test ..., non commento codice inutilizzato, lo rimuovo. E quando è il caso, commentare X lines è solo questione di una scorciatoia da tastiera.

Modifica: quindi sì, ho dimenticato di rispondere alla tua domanda esplicita, penso che non sia utile avere commenti speciali per il codice disabilitato. Se vuoi davvero conservare il codice, ma dì "non usarlo", puoi sempre contrassegnarlo come @deprecated ma non era questo il punto della tua domanda.