Codestyle moderno in MATLAB: cosa manca?

Question

Cerco di adottare uno standard di codifica per MATLAB, ma non sono sicuro di aver scelto quello giusto.

A mia conoscenza non c'è molto disponibile sul tema delle linee guida di programmazione per MATLAB, diverso da questo document. Il documento è ben scritto e ha buoni riscontri. Lo standard è stato pubblicato nel 2002 (su matlab central) da Richard Johnson, ma non è stato aggiornato da allora. C'è una versione aggiornata di o un documento simile? (Ho davvero fallito nel cercare su qualcos'altro).

Sfondo motivazione assume

• standard di codifica sono importanti
• Sebbene MATLAB non è cambia molto dal 2002, altre lingue e loro approcci hanno. Si potrebbe davvero beneficiare di tali pratiche.
• Il fatto è che molte persone stanno scrivendo un nuovo codice usando MATLAB o Octave. Anche se, si potrebbe sostenere che la lingua è praticamente morta (blah blah). Preferirei non andare lì (diciamolo come fuori programma).

Perché il codestyle non è abbastanza buono per me

vorrei riassumere qui un paio di cose. Se si prende il tempo di leggere il documento si potrebbe scoprire che

• cerca di essere troppo hungarian (è criptico e mi sono davvero odio questo nella maggior parte dei casi)
• ha troppe scorciatoie (più meno simile al punto precedente)
• non è supportato da Mathworks (ma in realtà potrebbe essere una buona cosa, poiché tutte le cose buone in MATLAB provenivano dalla comunità utente IMO)
• non ci sono strumenti di controllo qualità automatici che rispettino tale stile di codifica (qui non intendo qualcosa come mlint come nella famiglia * lint, ma più come pep8.py per python)

Immagino che il motivo per cui tale strumento non sia stato sviluppato è in realtà l'assenza di uno standard di codifica ampiamente accettato.

Apprezzerei molto le vostre critiche dello sullo standard o informazioni su una migliore.

Avete esperienza nel lavorare con questo standard? Quali parti di esso non ha funzionato per te? Se non hai mai utilizzato uno standard di codifica formale ma hai una pratica preziosa che non si adatta ad esso, ti preghiamo di fornire un esempio.

Answer 1

Una delle migliori risposte finora sarebbe quello di citare un commento di Amro:

"dello stesso autore (Richard Johnson)" ha pubblicato un book'The Elements of MATLAB Style' (vedi anche wiki) 2011:

Sommario

1. Principi generali
2. Formattazione
3. Naming
4. Documentazione
5. Programmazione
6. file e organizzazione
7. sviluppo.

Loren ha un blog con il review of the book. Mi limito a seguire qui linea di commenti:

• 7 Spalato codice lungo linee a Punti Graceful - Trovo che questo sia un utile in quanto si tratta di un dolore totale dover sentiero lontano a destra in qualsiasi editor, anche se è possibile.

• 10 Non utilizzare schede rigide - Questo aiuta a mantenere la sanità mentale quando si lavora in un gruppo con ambienti di editing possibilmente diversi.

• 43 Usa nomi significativi per variabili con un ambito di grandi dimensioni - Questo rende il codice molto più facile da leggere, capire e eseguire il debug, se necessario.

• 69 Funzioni Nome per quello che fanno - Dal momento che le funzioni di eseguire un'azione, il nome dovrebbe includere informazioni circa l'azione.

• 86 Uso ordinabili numerazione in Data Filesnames - Se si dispone di molti file di dati simili, con uno schema di numerazione razionale può solo aiutare.

• 97 Assicuratevi che i commenti siano d'accordo con il Codice - Non dimenticherò mai il tempo che il mio consulente di tesi mi ha chiamato perché era molto irritato. Gli avevo lasciato una copia di un programma Fortran che aveva molti commenti, l'ultimo era "Ignora tutti i commenti sopra, erano per una versione precedente".

• 135 Evitare codice criptico - Ho scoperto che in genere, la scrittura di codice criptico acquista meno di quanto mi aspetto in termini di cose buone e più mal di testa di quanto meriti. A volte, ho usato il codice criptico per le prestazioni in qualcosa di time-critical. Quando lo faccio, cerco di commentarlo completamente, inclusa un'implementazione diretta nei commenti che ho testato. In questo modo, quando cambiano i compromessi delle prestazioni, capisco cosa dovrebbe fare il codice e ho due opzioni di partenza per fare un aggiornamento del codice.

• 150, 151 Ridurre al minimo l'utilizzo di variabili globali e ridurre al minimo l'utilizzo di costanti globali - Direi che questo è ancora più forte. Esistono tecniche superiori per la gestione delle informazioni che si desidera condividere, che si tratti di handle di funzione, classi e relative proprietà o altri metodi.Queste tecniche sono molto più sicure da usare per molte ragioni - ad esempio, effetti collaterali più facilmente controllabili, se desiderato, e il codice diventa potenzialmente più adatto per il parallelismo.

• 172 Utilizzo Parenthese - La chiarezza del significato è fondamentale, soprattutto se gli altri hanno bisogno di capire, modificare o tradurre il codice.

• 176 Evitare l'uso di eval quando possibile - Sono sicuro che non sembra così per alcuni utenti di MATLAB, ma eval è evitabile il più delle volte.

• 185-188 Il primo di questi è Evitare espressioni condizionali Complicated - Queste voci contengono alcune riflessioni utili su come affrontare costrutti condizionali, l'ordinamento dei casi, ecc

• 271-275 Il primo di questi è scrivere piccoli test - Mi piace che Richard abbia messo alla prova un principio centrale di questa guida di stile. Non vedo come i programmatori funzionino bene senza una robusta suite di test.

Conclusione

Il libro sembra troppo generico rispetto al documento originale dal 2002. Io continuerò a leggerlo e dare ulteriori approfondimenti, ma non sembra soddisfare interamente la mia comprensione di severità richiesto per uno standard di codifica. Mette insieme molte idee generali utili per il programmatore principiante, ma non è rigoroso da programmare in modo che possano testare automaticamente il codice (di nuovo uno PEP8).