Dato che i programmatori sono autori e scrivono codice per esprimere pensieri e concetti astratti e che il buon codice dovrebbe essere letto da altri programmatori senza difficoltà e incomprensioni, un programmatore dovrebbe prendere lezioni di scrittura per scrivere codice migliore?

Astrarre concetti e problemi / entità del mondo reale è una parte importante della scrittura di un buon codice e una buona padronanza del linguaggio utilizzato per la codifica dovrebbe consentire al programmatore di esprimere i propri pensieri più facilmente o in un modo migliore. Inoltre, quando si tenta di scrivere o riscrivere un codice per renderlo migliore, si può dedicare molto tempo alla decisione dei nomi per funzioni, variabili o strutture di dati.

Penso che ciò potrebbe anche aiutare a evitare di scrivere codice con più di un significato, spesso causa di incomprensioni tra diversi programmatori. Il codice dovrebbe sempre esprimere chiaramente la sua funzione in modo inequivocabile.

1. Lezioni di scrittura? Non proprio.

La scrittura del codice sorgente è abbastanza diversa dalla scrittura di un libro.

Mentre entrambi perseguono gli stessi obiettivi: essere il più inequivocabile possibile ed essere facili da capire, lo stanno facendo in un modo molto diverso e le cose che uno scrittore dovrebbe imparare non sono le stesse cose che uno sviluppatore di software dovrebbe imparare.

Esempio 1: figure retoriche

Le figure retoriche sono preziose quando si scrivono romanzi, poesie, ecc., Poiché aumentano l'espressività della scrittura.

Qual è l'ultima volta che hai visto un ossimoro o una litote nel codice sorgente ? Aiuterebbe ad averli o sarebbe piuttosto dannoso per qualsiasi sviluppatore che dovrà mantenere tale codice sorgente in seguito?

Esempio 2: vocabolario

Il ricco vocabolario è molto apprezzato in letteratura. Il vocabolario di William Shakespeare, per esempio, è di ventimila-venticinquemila parole. Il vocabolario più ricco rende più interessante leggere un romanzo o una poesia.

Quando scrivi il codice sorgente, ti aspetti che venga letto da persone che non parlano molto bene l'inglese . Mostrando quanto conosci l'inglese sarebbe estremamente dannoso per il tuo codice. Se conosci una parola di fantasia che significa esattamente ciò di cui hai bisogno ma sai che molte persone non conoscono il significato di questa parola, dovresti piuttosto trovare un sinonimo meno espressivo o un insieme di parole che spiegano il significato. Un vocabolario di poche migliaia di parole è spesso in gran parte sufficiente per un determinato progetto.

Nota un aspetto importante: sebbene Google Translate possa essere di grande aiuto per un madrelingua, ci sono due problemi con qualsiasi traduttore:

• Una coppia di lingue non ha necessariamente una corrispondenza 1: 1 tra le parole. Alcune parole non hanno alcuna traduzione in altre lingue, oppure più parole potrebbero tradursi in una sola parola in una lingua straniera. Ad esempio, in russo, c'è un'enorme quantità di parole che colpiscono specifici stati di neve e tempo freddo, e tradurli in francese o spagnolo è solitamente impossibile senza perdere la loro specificità.

• Una parola a volte ha molteplici significati e il significato viene dedotto dal contesto. Google Translate, nonostante la sua alta qualità, di solito non è in grado di indicare il significato per nessuna delle situazioni più elementari.

Esempio 3: espressioni

Le espressioni rendono anche la prosa più ricca. Un autore si aspetta che un lettore abbia una certa quantità di cultura generale e sfrutta questa opportunità per rendere il testo più espressivo.

Analogamente all'esempio precedente, tali espressioni potrebbero essere molto problematiche se lette da persone che non sono madrelingua. Ma se il vocabolario generale di solito può essere tradotto, le espressioni sono molto più problematiche.

Ad esempio, l'inglese non è la mia prima lingua e, su base giornaliera, incontro espressioni, anche qui su StackExchange, che non conosco. Cerco di indovinarne il significato e a volte ho ragione. Ma a volte mi sbaglio, e cercare su Google quelle espressioni non aiuta.

Un utente nel suo commento mi ha ricordato un esempio che mi ha fatto soffrire a lungo quando ho appena iniziato a programmare: l' ago e il pagliaio di PHP . Non ero a conoscenza della corrispondente figura retorica, quindi ogni volta che leggevo la documentazione mi chiedevo di cosa si trattasse. Inutile dire che C # sequence.Contains(element)o gli eccellenti Python element in sequencesono un'alternativa molto migliore. Beh, almeno, gli sviluppatori che non conoscono l'ebraico hanno dovuto soffrire anche di PHP , ma questa è una storia diversa.

Esempio 4: riferimenti culturali

Riferimenti culturali In letteratura, è allettante includere elementi di una determinata cultura, e anche questo rende il libro più ricco e talvolta più interessante da leggere.

Tuttavia, il codice è indirizzato agli sviluppatori di tutto il mondo. Pertanto, ciò che è un ovvio riferimento per uno sviluppatore italiano potrebbe non essere così ovvio per uno russo, e ciò che ogni ragazzo o ragazza indiana conosce potrebbe non essere necessariamente conosciuto da un programmatore americano.

Lo stesso utente che ha parlato dell'ago e del pagliaio ha fornito anche un eccellente esempio di tale riferimento culturale: il Graal. Chi non sa cos'è il Graal? Bene, voglio dire, è "Graal" in francese, "Grial" in spagnolo e ... "Kutsal Kâse" in turco, ma comunque. Tuttavia, quanti sviluppatori americani o europei conoscono la storia medievale della Cina o dell'India? Perché qualcuno dovrebbe presumere che ogni programmatore cinese e indiano debba conoscere il riferimento al Santo Graal?

2. Lezioni per scrivere codice sorgente espressivo? Sicuro.

• Qualsiasi sviluppatore dovrebbe imparare a scrivere codice sorgente espressivo.

• Qualsiasi sviluppatore dovrebbe spiegare perché il commento in:

  int j = i + 1; // Creating i and adding 1 to it.
  

  fa male, a parte il fatto che è totalmente sbagliato.

• Qualsiasi sviluppatore dovrebbe essere in grado di comprendere il refactoring di base e come aiuta a rendere più espressivo il codice sorgente.

• Qualsiasi sviluppatore dovrebbe ricordare che il 20% del tempo è dedicato allo sviluppo del codice e l'80% del tempo a mantenerlo. Per alcuni progetti, è più simile al 5% - 95%.

• eccetera.

In sostanza, la programmazione è vicina alla documentazione tecnica. Una persona che scrive una scheda tecnica per un bolt deve prendere lezioni di scrittura? Non proprio. Lo stesso vale per gli sviluppatori. Chiunque dovrebbe scrivere senza commettere errori di ortografia in ogni parola e chiunque dovrebbe essere in grado di comunicare le proprie idee in modo abbastanza chiaro. A parte questo, non sono sicuro di come scrivere lezioni sarebbe più utile di, diciamo, un corso di informatica o di sicurezza IT o altro.

L'espressività del codice sorgente può essere appresa con altri mezzi. superM ne ha menzionato uno nella sua risposta : leggere un buon codice. Posso citarne alcuni altri:

• Leggere libri come Beautiful Code o Code Complete,

• Chiedere a uno sviluppatore più esperto di rivedere il tuo codice,

• Comprensione dei modelli e come e quando usarli.

un programmatore dovrebbe prendere lezioni di scrittura per scrivere codice migliore?

No. Un programmatore dovrebbe prendere lezioni di scrittura per imparare a scrivere una prosa migliore. Un programmatore dovrebbe prendere lezioni di programmazione per imparare a scrivere codice migliore. Nonostante alcune somiglianze, scrivere prosa e scrivere codice sono abbastanza diversi.

Questo non vuol dire che i programmatori non dovrebbero prendere lezioni di scrittura. Dovrebbero! Alcuni motivi:

• Scrivere è un'abilità essenziale per qualsiasi persona istruita. Sembrerai più intelligente se sai scrivere bene.

• Nonostante i loro migliori sforzi, i programmatori spesso devono comunicare con altri umani, spesso usando la parola scritta.

• Apprendi abilità oltre a scrivere nelle lezioni di scrittura, e quelle sono spesso utili ai programmatori. Ad esempio, imparerai a discutere del lavoro di altre persone senza ferire i loro sentimenti e imparerai ad accettare le critiche degli altri senza prenderlo sul personale.

Il mio codice dipende sempre più dalla creazione di un vocabolario condiviso tra il business e i team tecnici. Direi che migliorare le tue capacità di scrittura può aiutarti a ridurre l'ambiguità e le incomprensioni in questi sforzi, ma che probabilmente non aiuterà l'espressività del tuo codice.

La nozione letteraria di espressività non è la stessa della programmazione di espressività. In molti casi, l'ambiguità nel linguaggio può essere usata come un dispositivo letterario, anche nella saggistica, in una forma che aumenta l'espressività, perché innescherà nel lettore varie associazioni culturali, linguistiche e simboliche, sia intenzionali che non intenzionali. Questo tipo di espressività non è desiderabile nella programmazione; l'astrazione è più preziosa dell'ambiguità. Nella programmazione, l'astrazione aumenta la flessibilità con forse qualche costo del carico cognitivo. L'astrazione in forma letteraria può avere l'opposto dell'effetto che ha nella programmazione: più la tua scrittura è astratta, più è probabile che il lettore abbia la percezione di non dire nulla. Tutti quei simboli e associazioni che derivano da un discorso concreto hanno valore,

Tuttavia, un programmatore non è una macchina. Gli esseri umani traggono beneficio in modi spesso inaspettati dalla crescita intellettuale ed emotiva. Migliorare la tua scrittura può tradursi in una maggiore empatia del cliente perché ti costringi a lottare con le sfide della comunicazione; forse ti sentirai per quel cliente che dice quello che vogliono, poi lo consegni e capiscono che non è quello di cui hanno bisogno. Forse imparerai a concentrarti su ciò che non è stato detto.

Forse imparare a gettare argilla su un tornio ti aiuterà a vedere dei parallelismi tra artigianato e sviluppo del software. Studiare il modo in cui gli architetti della costruzione comunicano potrebbe portarti ad apprezzare maggiormente la costruzione di un vocabolario dei modelli di progettazione nella programmazione. Studiare la biologia potrebbe portarti ad affascinanti intuizioni su come le formiche e le api trovano e comunicano sulle fonti di cibo e su come quei semplici meccanismi possano essere tradotti in algoritmi di pathfinding.

Imparare cose al di fuori del tuo dominio principale è utile perché le persone curiose creano sviluppatori migliori delle persone che non lo sono.

Per quello che vale, ero quasi un grande specialista in letteratura; Ho finito per passare agli studi sull'Asia orientale perché ero più interessato alle lezioni che frequentavo in quel dipartimento. C'è una possibilità che non potrei essere nel settore se non avessi studiato gli studi dell'Asia orientale, perché l'effetto collaterale dello studio del giapponese mi ha reso più prezioso all'epoca, quando una società di software mi ha assunto in parte a causa delle competenze linguistiche. Dovevo ancora creare un portafoglio più profondo di competenze tecniche, ma gli effetti collaterali non voluti dell'apprendimento di qualsiasi cosa possono renderti un professionista del software migliore e più pertinente.

Quando i progetti di programmazione falliscono, di solito sono dovuti a comunicazioni fallite, generalmente in base ai requisiti. Sebbene una conoscenza mediocre dell'inglese possa essere sufficiente per scrivere effettivamente il codice, essere un buon comunicatore è essenziale per scrivere il codice giusto. In questa epoca di comunicazione a distanza, basata su testo, la scrittura inglese è un'abilità comunicativa molto importante.

Detto questo, la tua domanda è scritta in modo molto chiaro e conciso, meglio della maggior parte dei programmatori con cui ho lavorato. Non avendo visto il tuo codice, ti suggerirei di concentrarti sull'esprimersi nel linguaggio di codifica che preferisci. Per Java, consiglio il libro di Joshua Bloch, "Effective Java".

Come gli scrittori vengono insegnati leggendo i classici del mondo, quindi i programmatori vengono educati leggendo un buon codice. Ma c'è un piccolo problema. Mentre ci sono giganti riconosciuti in letteratura, ce ne sono pochi nella programmazione. E se ci sono, potrebbero "parlare" una lingua diversa. (Non sono nemmeno sicuro che sia ragionevole consigliare di leggere il codice sorgente Minix di Tanenbaum)

Esistono molti modi popolari per rendere il codice più leggibile (=> gestibile), come scrivere commenti, dare nomi significativi, ecc. Inoltre, molte aziende stabiliscono le loro regole di scrittura del codice e rende tutto molto più semplice.

Comunque, come molti scrittori eccellenti, i programmatori non sono mai contenti del proprio codice. Quindi sapere quando fermarsi è importante quanto scrivere un codice di qualità.

Trovo sempre semplicemente fermarmi dopo ogni bit di codice che scrivi e leggerlo di nuovo, immaginando di non averlo mai visto prima, mi fa fare molta strada.

Ancora meglio è chiedere a un amico che ha familiarità con la programmazione di leggere il tuo codice senza dirgli cosa fa.

Non penso che sarà di aiuto; la scrittura creativa riguarda trame, sviluppo del personaggio e dialoghi, non l'espressione di concetti tecnici con chiarezza. La scrittura tecnica potrebbe aiutare, ma ne dubito - sono solo tipi di scrittura molto diversi!

e nota che il codice "leggibile" è soggettivo e principalmente una questione di stile sintattico e modi di dire comuni (che variano tra le lingue e persino tra i team)

la scelta di buoni nomi per variabili, classi e metodi, tuttavia, è importante. Ogni sviluppatore diventa, in una certa misura, un esperto in materia in alcuni aspetti del dominio in fase di sviluppo, quindi è fondamentale un corretto utilizzo della terminologia del dominio.

le revisioni tra pari possono aiutarti a creare vocabolario e fiducia

C'è sicuramente una grande differenza tra scrivere codice e scrivere prosa.

In prosa le frasi sono collegate (o separate) dal tempo (il modo in cui si susseguono per raggiungere un fine o un significato) ma nel codice (efficiente) è possibile (ri) caricare parti della 'storia' da tabelle con ripetibili azioni / reazioni. Quindi, l'interazione con il lettore (in prosa) o l'utente (del codice) è totalmente diversa.

In un altro modo, scrivere prosa "piacevole" e scrivere un codice "bello" sono simili: imparare a scrivere (codice o prosa) è un processo che comporta molti errori (o pensare / testare miglioramenti o riformulare) per ottenerlo " elegante'.

Penso che il sistema chimico periodico degli elementi sia elegante, a causa del modo molto compatto in cui descrive alcune proprietà fondamentali dei materiali di base che usiamo, un po 'come un codice efficiente, ma non è certamente in prosa. Uno scherzo ha molte qualità in prosa (farti entrare in un certo stato d'animo, mantenerlo e poi cambiarlo, quando inaspettato), ma è una pratica di codifica terribile.

Ma entrambi i tipi di scrittura richiedono artigianato.

dal mio punto di vista l'inglese e la grammatica di base sono sufficienti per un programmatore. Ma qualsiasi cosa per interrompere una routine di programmazione monotona sarà sempre rigenerante e quindi le lezioni di scrittura saranno rilassanti per i programmatori.