Un linguaggio di programmazione in base alla progettazione può imporre un "codice pulito"? [chiuso]

Quindi sto programmando i miei primi progetti in C ++ e sembra che ci voglia uno sforzo maggiore per rendere il codice "pulito", piuttosto che semplicemente funzionare. Cioè sembra che C ++ "permetta" di scrivere codice brutto, ma funzionante.

Che mi ha fatto pensare

Un linguaggio di programmazione può imporre un codice pulito in base alla progettazione? Esistono già tali lingue?

Inoltre, come vengono incorporati come principi di progettazione nello sviluppo / teoria del linguaggio di programmazione? Che tipo di misure vengono utilizzate?

L'effetto principale che il design del linguaggio ha sul "codice pulito" è a livello sintattico. Le lingue con molte scorciatoie e operatori oscuri (Perl / APL) si prestano a codice "sporco", mentre le lingue con un insieme più piccolo di elementi (diciamo, Python) si prestano a un codice più pulito.

La semantica, tuttavia, è un animale molto diverso. Non è possibile imporre che la semantica di una lingua venga utilizzata in modo pulito, soprattutto perché non è possibile, come compilatore, sapere cosa l'utente della lingua sta cercando di realizzare. Uno strumento potente è semplicemente questo: uno strumento potente, nel bene o nel male.

Alla fine della giornata, la semantica è più importante della sintassi. È anche la parte più difficile da capire come sviluppatore di manutenzione (ad es. "Cosa significa effettivamente questo codice? Capisco cosa fa ...").

Di conseguenza, direi che non esiste un progetto per imporre il codice pulito, ma è possibile scrivere una sintassi semplice con semantica pulita che lo rende più semplice. Nel bene e nel male, il codice pulito è principalmente una questione di conoscenza, motivazione, disciplina e competenza degli sviluppatori.

Le lingue possono forzare o incoraggiare i programmatori ad affrontare alcune classi di bug, che fa parte della definizione di codice pulito. Ad esempio, varie lingue svolgono un lavoro relativamente decente di indirizzamento:

• Eccezioni puntatore nullo.
• Bug di stato condivisi.
• Problemi di concorrenza.
• Eccezioni non selezionate.

Ciò ti rende solo parte del percorso, però, perché il codice pulito riguarda principalmente la comunicazione da uomo a uomo . I linguaggi di programmazione hanno davvero solo una leva per aiutare in questo, e questo è il loro potere espressivo . È un termine davvero difficile da definire, ma sostanzialmente è più facile per i bravi programmatori scrivere codice più pulito in linguaggi più espressivi. Hanno più strumenti disponibili per esprimere facilmente un algoritmo in termini che comunicano bene con altri umani. Non fraintendetemi, potete scrivere codice pulito in ( quasi ) qualsiasi linguaggio di programmazione. Sono solo alcune lingue a renderlo più semplice e avere un risultato relativo migliore.

Tuttavia, non puoi semplicemente comporre l'espressività e magicamente le persone inizieranno a scrivere codice migliore. Con la maggior parte dei programmatori, dai loro più manopole per girare nella loro lingua e non sapranno come usarli correttamente, quindi il loro codice finisce davvero peggio. Ci vuole disciplina e buon mentoring per migliorare la qualità del codice. Non ci sono proiettili d'argento.

In una certa misura. Molte lingue sono progettate deliberatamente per incoraggiare alcune forme di codice pulito secondo gli ideali dei progettisti linguistici. È certamente possibile scrivere codice brutto e incomprensibile in qualsiasi lingua, ma alcune lingue fanno uno sforzo maggiore per scoraggiarlo.

Ad esempio Python ti costringe a rientrare i blocchi in base alla struttura semantica della lingua, mentre molte altre lingue ti permettono di rientrare totalmente a caso o per niente. Questo è un esempio di una lingua che incoraggia attivamente un certo ideale di pulizia.

Se riesci a quantificarlo, puoi creare una lingua in grado di ottimizzarlo.

Sebbene non conosca alcun linguaggio particolare che imponga effettivamente una politica di "codice pulito", i poliziotti di stile che vengono eseguiti su build sono abbastanza comuni.

Il motivo principale per cui questo è un passaggio separato dall'essere inserito nella lingua è in gran parte una funzione delle priorità. È nel migliore interesse di un linguaggio di programmazione consentire la massima flessibilità ai programmatori per ottenere il più ampio livello di adozione. Esistono così tanti linguaggi di programmazione e DSL diversi che limitano artificialmente la base di utenti essendo esigenti e motivati ​​su ciò che l'input è consentito potrebbe ostacolare una più ampia adozione.

Ad esempio, non è nel migliore interesse di C # forzare le persone a scrivere

if (condition)
{

invece di

if (condition) {

Ma i controllori di stile possono essere considerati pignoli perché è quello che sono progettati per fare.

Quindi, per rispondere alla domanda

Un linguaggio di programmazione può imporre un codice pulito in base alla progettazione?

_{enfatizzare il mio}

Assolutamente, purché tu fornisca una definizione forte di cosa significhi "codice pulito".

Ad esempio, potrei definire "codice pulito" per significare:

• lunghezza della riga non superiore a 80 caratteri
• funzioni composte da non più di 100 righe
• il rientro deve essere di due spazi
• parentesi graffe aperte devono seguire alla fine della linea preceduta esattamente da uno spazio
• non più di due operatori per riga

e potresti non essere d'accordo con alcune o tutte queste convenzioni, ma alla fine queste sono quantificabili e possono essere applicate a livello di programmazione.

No, non nel senso che descrivi. Rilevare "bruttezza" non può essere fatto automaticamente!

Tuttavia, i progettisti di lingue possono fare qualcosa per incoraggiare il buon codice (non voglio dire "pulito" perché a volte il codice buono e sicuro è anche lungo e "brutto"). Ad esempio, i progettisti del linguaggio Rust hanno esaminato le cose che i programmatori C ++ disciplinati tendono a fare (come dare ai valori allocati in heap un unico "proprietario") e hanno reso più semplice fare alcune di queste cose. Ciò include la fornitura di un typechecker che è possibile utilizzare per verificare che non siano stati commessi alcuni errori comuni.

Direi che un buon design del linguaggio è spesso reattivo: i designer guardano cosa fanno i bravi programmatori e cercano di renderlo più facile e "più bello".