View Full Version : Regole di buona programmazione
Salve, mi interessa capire quali possono essere i confini per tracciare un profilo del classico e bravo programmatore, per iniziare ho notato una piccolezza, specialmente usata da persone che codificano ad alti livelli, l'uso del ";" dopo un blocco di istruzioni {}, la mia domanda è, a che pro fare una cosa del genere?
...{
...
};
...
IngMetallo
04-08-2011, 09:34
Io ho cominciato a studiare programmazione da pochi mesi.. quindi non posso certamente darti i parametri di un buon programmatore ^^"
Per quanto riguarda il " ; " dopo un blocco di codice mi viene da risponderti banalmente che ci sono strutture che richiedono il ";" dopo la chiusura dell'ultima parentesi.. Vedi lo struct, la definizione delle classi ecc.
Almeno per il C++ o.o Sicuramente altri sapranno dirti di più.. purtroppo quese sono le mie conoscenze xD
Salve, mi interessa capire quali possono essere i confini per tracciare un profilo del classico e bravo programmatore, per iniziare ho notato una piccolezza, specialmente usata da persone che codificano ad alti livelli, l'uso del ";" dopo un blocco di istruzioni {}, la mia domanda è, a che pro fare una cosa del genere?
...{
...
};
...
1) Non hai specificato il linguaggio.
2) Assumendo che tu stia parlando di C/C++ e derivati, ci sono solo 2 casi in cui dopo una parentesi chiusa si mette il punto e virgola, e cioè dopo la definizione di una struttura o di una classe:
struct x {
...
}
class y {
...
};
Ciò perchè le parentesi graffe delimitano la definizione dei contenuti dei due tipi di strutture.
Quando invece le parentesi servono per delimitare un blocco di codice, il punto e virgola NON va messo alla fine.
In questo esempio:
if(x) {
y;
};
Il compilatore NON darà errore, perchè viene interpretato come
if(x) {
y;
}
;
cioè un if che esegue un blocco di codice, seguito da un'istruzione vuota.
Tuttavia, ci sono casi in cui mettere il punto e virgola rende il codice errato e, se ti va bene, causa un errore di compilazione, come in
if(x) {
y;
};
else
z;
In questo caso, il compilatore da un errore, del tipo "else senza if", perchè viene interpretato come
if(x) {
y;
}
; // istruzione vuota che "rompe" l'if
else
z;
Questo è la teoria e la pratica.
Puoi fare un esempio del codice dei programmatori "degli alti livelli" ?
Bisogna vedere cosa intendi per regole di buona programmazione, se dal punto di vista della leggibilità del codice oppure dal punto di vista logico.
Per quanto riguarda la leggiblità del codice ci possono essere delle pratiche più o meno comuni, come ad esempio quello di usare nomi lunghi per descrivere bene cosa fa una data funzione o una variabile.
Ad esempio:
SearchSubstring(..)
E' sicuramente meglio di quello scempio C (ed in generale di molte funzioni *nix :asd: ) che è:
strstr()
Che non dà minimamente l'idea di cosa faccia.
Non esiste uno standard in tal senso, ovvero se lavori in team in genere si cerca di usare delle regole comuni, mentre se lavori da solo puoi cercare di dartene te qualcuna, ad esempio "scrivere i tipi tutti in minuscolo e iniziare i nomi delle variabili con la lettera maiuscola" o viceversa...
Purché tu sia coerente con le scelte che fai.
Relativamente alla logica di funzionamento, buona programmazione è controllare sempre e comunque che un puntatore sia valido, oppure inizializzare SEMPRE la memoria con calloc (o quantomeno assicurarsi di inizializzare tutti i campi delle strutture allocate con malloc).
Ma non solo, in generale controllare sempre il ritorno di una funzione o crearti un sistema di gestione degli errori (se stai lavorando in C) in maniera da uniformarne il trattamento.
Salve, mi interessa capire quali possono essere i confini per tracciare un profilo del classico e bravo programmatore
Puoi partire da qui http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond
per iniziare ho notato una piccolezza, specialmente usata da persone che codificano ad alti livelli, l'uso del ";" dopo un blocco di istruzioni {}, la mia domanda è, a che pro fare una cosa del genere?
...{
...
};
...
Non credo serva a nulla di utile in nessun linguaggio che conosco. Cosa vuol dire "codificano ad alti livelli"? :confused:
cdimauro
10-08-2011, 17:34
Io, invece, partirei da qui (http://simson.net/ref/ugh.pdf). :D
banryu79
11-08-2011, 16:36
Io, invece, partirei da qui (http://simson.net/ref/ugh.pdf). :D
Vale la pena leggerlo solo per alcune massime che mi hanno ucciso di risate, tipo:
If the automobile had followed the same development as the computer,
a Rolls-Royce would today cost $100, get a million miles per
gallon, and explode once a year killing everyone inside.
e
Unix is computer-scientology, not computer science.
oppure
Two of the most famous products of Berkeley are LSD and Unix. I
don’t think that this is a coincidence
:asd:
Risate a parte, è una lettura dall'alto valore educativo.
i compilatori sono diventati così "potenti", non mi veniva altro termine, forse era meglio dire "flessibili" che danno la sensazione di digerire di tutto. A volte ho questa sensazione che anche programmi scritti in maniera casareccia riescono a volare lo stesso.
Le uniche buone regole di programmazione che mi sento di suggerire sono: scrivere, scrivere e riscrivere e migliorare quintalate di codice per fare molta ma molta esperienza; le regole che intendi tu vengono cammin facendo.
Imparare ad usare bene gli algoritmi noti e non reinventare ogni volta l'acqua calda è una buona regola di programmazione.
Scrivere codice che può essere riusato è un'altra regola di programmazione. Produrre la documentazione del programma che si sta sviluppando sottolineando le proprie scoperte è un'ottima regola.
Salve, mi interessa capire quali possono essere i confini per tracciare un profilo del classico e bravo programmatore
Quelle che hai descritto sono regole di stile nella scrittura del codice sorgente.
Ce ne sono di vario tipo (ed esistono pure dei "formattatori di codice sorgente" tipo astyle che lo riformattano in vari tipi di "bello stile di scrittura").
Di solito grossi progetti open source ed organizzazioni "fissano uno stile di scrittura" in modo che sia più semplice leggere, comprendere e modificare il codice scritto da altri.
Un vero programmatore non lo riconosci per lo stile di scrittura dei sorgenti (anche se quello di solito è un indicatore utile), ci sono un sacco di pessimi programmatori che seguono le regole di scrittura ma comunque scrivono cose abominevoli. ;)
Io, invece, partirei da qui (http://simson.net/ref/ugh.pdf). :D
E' un libro datato, tre quarti delle critiche mosse non hanno piu' senso... e le altre sono valide per qualsiasi sistema operativo attuale :D.
Va cmq letto perche' e' una lettura divertente, ma ha molta piu' utilita' il link postato da shinya
Quelli del "worse is better"? :rolleyes:
No grazie. La correttezza del codice è quello che distingue un vero programmatore dalle "scimmie ammaestrate" :asd: .
Un vero programmatore non lo riconosci per lo stile di scrittura dei sorgenti (anche se quello di solito è un indicatore utile), ci sono un sacco di pessimi programmatori che seguono le regole di scrittura ma comunque scrivono cose abominevoli. ;)
Ti quoto pienamente
Quelli del "worse is better"? :rolleyes:
No grazie. La correttezza del codice è quello che distingue un vero programmatore dalle "scimmie ammaestrate" :asd: .
Ma avete letto i punti indicati da shinya ? Non sono neanche una ventina, e secondo me ampiamente condivisibili.
Ma avete letto i punti indicati da shinya ? Non sono neanche una ventina, e secondo me ampiamente condivisibili.
interessanti, alcuni sono i medesimi che avevo sentito a ingegneria del software. Purtroppo, passato l'esame ci si dimentica di tali particolarità (punti).
Comunque non è sempre facile riuscire a tenere sotto controllo un progetto, forse la filosofia unix che prevede che ogni comando faccia una cosa sola, questo mi era stato insegnato al corso di laboratorio di sistemi operativi, è la soluzione migliore.
CLS o CLEAR cancella solo lo schermo e non CLS -t -v -u fa qualcosa d'altro.
Ma avete letto i punti indicati da shinya ? Non sono neanche una ventina, e secondo me ampiamente condivisibili.
Ma no, credo che sia solo una questione allergica. Basta leggere "Unix" e si scatena il finimondo :)
Protip: i punti del link con unix non c'entrano un cazzo.
Ma avete letto i punti indicati da shinya ? Non sono neanche una ventina, e secondo me ampiamente condivisibili.
Sono ampiamente condivisibili, ma non sono tutto.
Ad esempio un buon programmatore tiene sempre d'occhio come procede lo sviluppo in modo da rifattorizzare e/o riscrivere per tempo le parti che lo richiedono (ma questo vale se si ha il controllo su tali aspetti).
Poi non basta la chiarezza o la pulizia del codice scritto, bisogna tenerne aggiornata la documentazione interna ed esterna (commenti, documentazione descrittiva "estraibile automaticamente" con tool tipo doxygen e vera e propria documentazione scritta separatamente), non solo per gli altri ma anche per se stessi (tipo per quando si riprende in mano del software scritto anni prima).
Non parliamo poi del tenersi aggiornati anche a livello di tool e di teoria, ecc. ecc. e poi di applicarne le parti utili relative al proprio lavoro.
Ad esempio se si programma ad oggetti è estremamente consigliabile aver chiari i design pattern (ed anche gli anti-pattern ;) ) e saperne fare buon uso.
supersalam
12-08-2011, 23:10
Le regole più importanti secondo me sono:
-Commentare ogni riga.
-Mettere in maiuscolo le costanti.
-Rendere il nome delle variabili significativo.
-Indentare le graffe in modo da rendere i blocchi più chiari.
Ovviamente ci sono anche regole che migliorano l'esecuzione di un software ma dipendono dal linguaggio ovviamente.
Ma no, credo che sia solo una questione allergica. Basta leggere "Unix" e si scatena il finimondo :)
Protip: i punti del link con unix non c'entrano un cazzo.
Diciamo che leggerli nella stessa pagina in cui compare "Unix philosophy" insieme a "worse is better" fa un certo effetto :asd:
L'ingegneria del software è una disciplina abbastanza recente, credo che nessuno abbia in tasca la soluzione ideale.
Tant'è che ci sono talmente tante teorie e modi di vedere le cose che si creano fazioni anche su quelle pratiche.
Su molti punti si può essere d'accordo, ma la realtà ci insegna che spesso la teoria è una cosa mentre la pratica è un'altra cosa.
Una cosa che secondo me dovrebbe valere sempre e su cui tutti dovrebbero essere d'accordo è la correttezza degli algoritmi che si scrivono/usano.
Bisogna rendersi conto che la complessità fa parte del mondo, va gestita ma non ignorata o peggio ancora banalizzata cercando di semplificare anche le cose che non si possono semplificare.
Ci sono cose semplici e cose meno semplici, la mania di semplificare tutto spesso porta ad errori anche grossolani.
L'ingegneria è l'arte del compromesso, ma la qualità del codice non va giudicata dai principi usati in teoria per scriverlo, quanto dal codice stesso.
Anche perché ognuno è libero di interpretare a suo modo quei punti.
-Commentare ogni riga.
:Puke:
No dai :asd:
cdimauro
20-08-2011, 09:31
Ma anche "Mettere in maiuscolo le costanti" non suona bene... :stordita:
Certo, quella sui commenti è veramente pesante. :D
@shinya: purtroppo Unix ha fatto anche parecchi danni. Ha senz'altro contribuito alla storia dell'informatica con alcuni concetti interessanti, ma il mondo non è Unix-centrico, e tanti altri concetti sono obsoleti, senza senso, o addirittura disattendono la filosofia originale (la più grossolana: è normale avere comandi con decine e decine d'opzioni per farti anche il caffè?)
Poi, per carità: i gusti son gusti, eh! ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.