La formattazione del codice deve avere importanza?

5

AGGIORNAMENTO: un problema deriverebbe da cose che non sono strettamente definite da un formattatore, come linee vuote consecutive ecc., che andrebbero perse nel processo (da locale a server a riformattazione locale) che infastidirebbero le persone (anche io :)

Sono abituato ad adottare un formattatore di codice condiviso, quindi la mia domanda non riguarda "dovrei inviarmi?"

Mi chiedo se questo (la formattazione del codice) debba avere importanza? Non è possibile che il tuo repository memorizzi i tuoi commit in una formattazione "predefinita"? Non vedresti mai come si presenta questo stile, perché ogni volta che esegui il checkout tutte le fonti vengono salvate sul tuo HDD dopo essere state riformattate usando il tuo formattatore. Inoltre, ogni volta che navighi nel repository, il tuo cliente ti mostrerà la sorgente riformattata usando il tuo formattatore. Anche tutte le diff saranno fatte dopo la riformattazione usando il tuo formattatore.

È possibile farlo? (Ad esempio plug-in client, configurazione del repository, ecc.)

    
posta Jaroslav Záruba 01.11.2014 - 23:03
fonte

3 risposte

4

Tecnicamente, il problema principale che vedo è con i numeri di riga e il debug. Se si riformatta il codice, il codice potrebbe essere visualizzato su righe diverse, rendendo molto più difficile dare un senso agli stacktraces e così via. Anche il riferimento al codice in generale sarebbe molto più difficile, se i tuoi colleghi vedono linee diverse da te.

Nel contesto della collaborazione, penso che la riconoscibilità del codice sia importante. Se guardo lo stesso codice sullo schermo di un collega, sarebbe molto più difficile collaborare se non riconosco facilmente il codice.

    
risposta data 02.11.2014 - 19:10
fonte
3

C'è uno strumento eccellente uncrustify che prende una descrizione della formattazione del codice sorgente da un file di configurazione ed emette un file formattato come da specifica nel file di configurazione. Tuttavia, ci sono alcuni problemi con questo approccio, i più ovvi e importanti sono:

  1. Il file memorizzato nel repository sarà diverso dalla vista del tuo file, rendendo più difficile l'analisi delle differenze.

  2. Sarà molto più difficile per te mantenere le modifiche dello spazio bianco separate dai commit importanti.

Sono sicuro che c'è di più.

    
risposta data 01.11.2014 - 23:11
fonte
3

Non avere regole non è libertà, è solo caos. Come si potrebbe scrivere un libro sul linguaggio di programmazione senza standard di codifica? Riesci a immaginare che ogni libro abbia una formattazione completamente diversa?

Ho preferenze personali su come dovrebbe apparire il codice, ma la mia personalità non è molto importante quando lavoro in una squadra. La collaborazione è importante e gli standard di codifica lo rendono possibile , non solo più semplice.

Is this possible to do? (E.g. client plugins, repository configuration, etc.)

Sì, ma con prestazioni, bug e fase di installazione aggiuntivi peggiori. Ho abbastanza configurazione e plugin grazie a Maven, quindi è meglio attenersi alla buona vecchia disciplina.

Tuttavia, vi è un'idea sull'archiviazione di un programma non come codice sorgente, ma come albero di sintassi. Come AST indipendenti dalla lingua e roba del genere.

Aggiornamento: sui commenti.

Capisco e capisco il tuo punto, ma continuo a credere che le mie preoccupazioni siano vere.

Immagina di avere quei plugin magici che astraggono la formattazione. Combatti e codifica con altre persone senza conoscere le loro preferenze, ed è tutto doppio arcobaleno in tutto il cielo =)

Quindi, uno dei tuoi colleghi ti dice qualcosa del tipo: "Sto scrivendo un libro sulla programmazione, ho bisogno del tuo aiuto." Poi ti manda un manoscritto e vedi che è andata completamente in direzione opposta non solo con la formattazione, ma anche con la sintassi concreta. Immagina che abbia inventato qualcosa come CoffeeScript in cima al linguaggio che usi entrambi: le parole chiave sono differenti, i costrutti di sintassi più brevi, ecc. È totalmente possibile quando hai un tale plugin magico e la gente lo farà (a causa della legge di Murthy e t no joke).

Quindi, non puoi aiutarla, a meno che tu non rifiuti entrambe le tue preferenze personali e usi la formattazione "standard", "predefinita" e la sintassi concreta. Ta-a-da-un!

Quindi rivendico:

  1. Se ci sono N persone e ognuno è autorizzato ad avere i propri stili di sintassi e formattazione, alla fine ci saranno N stili differenti.
  2. Se ci sono persone che usano questi stili diversi, potrebbero scrivere libri usando questi stili diversi o accettare l'uso di "default".
  3. Se si finisce per utilizzare comunque "default" per poter collaborare, perché preoccuparsi della personalizzazione?

Non insisto su "purezza" o qualcosa del genere. Lavoro con il codice che spesso ha un mix di diversi stili di formattazione. Ma sono soprattutto piccole differenze che non influenzano la lingua. Sto completamente bene con quello.

Ma non voglio imparare una nuova lingua solo per nutrire l'ego di qualcuno (anche il mio, se è per questo). A volte copio il codice di copia e incolla nel mio programma di messaggistica istantanea e non voglio avere alcun plug-in in esso (su entrambi i lati del mio e del destinatario, farò sapere) per inviare uno snippet.

Se hai un tale plugin magico nel tuo IDE, devi avere tali plugin ovunque tu voglia attaccare il tuo codice. Non è altro che ulteriori problemi.

Riepilogo: puoi farlo, ma non dovresti. Gli standard sono migliori quando si personalizza. Le convenzioni sono migliori dei plugin.

Aggiornamento 2:

La persona immagine A preferisce mettere una parentesi graffa su una linea separata:

while (true) // endless loop
{

Quindi questo codice può essere memorizzato in una sorta di albero di sintassi e quindi mostrato alla persona B, che usa lo stile egiziano. Questo può essere fatto in questo modo:

while (true) /* endless loop */ {

o così:

// endless loop
while (true) {

E questo secondo ha un diverso ordine di token.

Questo mostra che non tutti i costrutti di sintassi si adatterebbero in questo modello. Quindi la lingua dovrebbe essere probabilmente limitata in molti modi per fornire la possibilità di personalizzare la formattazione. Credo comunque che sia possibile, dal momento che ci sono linguaggi di programmazione come Blockly di Google che hanno sintassi completamente concreti e "memorizzati".

A proposito, Blockly è una dimostrazione del concetto, dal momento che puoi personalizzare completamente il frontend per adattarlo al tuo gusto artistico.

    
risposta data 02.11.2014 - 00:18
fonte

Leggi altre domande sui tag