Gestione e documentazione del codice: regole, convenzioni e licenze software

Gestione e documentazione del codice

Regole e convenzioni di codifica

Tutti i progettisti di software adottano convenzioni di stile o linee guida per la scrittura del codice sorgente dei programmi. Le convenzioni di codifica non vanno confuse con le regole di sintassi del linguaggio usato. Le regole di sintassi vengono controllate dal compilatore e non possono essere violate altrimenti non verrà nemmeno generato il codice eseguibile. Le convenzioni di codifica invece sono stabilite e controllate dai programmatori. Il loro mancato rispetto di per sè non compromette la funzionalità o l'efficienza del codice generato, ma rende più difficile la lettura del codice da parte degli umani. Sarà quindi più difficile la manutenzione, la ricerca di errori, l'aggiornamento del codice, ecc.Esempi float pippo; int pluto pippo = 0,3 ; In queste righe di codice c++ sono violate due regole di sintassi int dividendo; int Divisore, RESTO, xZy; .. if (RESTO == 0) cout ("divisione senza resto") ; In queste righe non ci sono errori di sintassi ma sono violate diverse convenzioni di codifica comuni:Esempi di convenzioni comuni di codifica per C++

• Regole di denominazione generali
• Convenzioni per nomi di file, tipi, varabili, costanti, funzioni
• Indentazione del codice
• Evitare uso di istruzioni goto
• ecc.Le convenzioni di codifica aiutano anche a prevenire errori comuni Esempi: if (x=0) y = 0; else y = x+1; Questo codice contiene un errore comune. int eta media; _ Eta media = totale/numero; _ Un altro esempio: scrivendo i nomi delle variabili sempre in minuscolo e senza abbreviazioni si riduce il verificarsi di errori dovuti al fatto che in alcuni punti la variabile abbia un nome diverso rispetto a quello stabilito nella dichiarazione. Errore: unknown identifier

DEFINIZIONE: la naming convention è un insieme di regole per la scelta della sequenza di caratteri da utilizzare per gli identificatori di variabili, tipi, funzioni e tutte le altre entità nel codice sorgente e nella documentazione. Per questo è importante seguire poche - ma efficaci! - regole per la stesura del codice:

1. Consistenza: Mantenere una coerenza nella scrittura del codice è importante per dare senso a quello che si sta scrivendo; 1 getName ( { ... } 2 retrieveName {.} 3 bringBackName { ... }
2. Significativo: Scegli una parola per sintetizzare un concetto. Essere sintetici non vuol dire scrivere parole brevi o utilizzare identificatori poco discorsivi. Si può essere esplicativi scrivendo le parole giuste nel giusto contesto. Utilizzare una naming convention troppo generica potrebbe essere fuorviante; 1 const USERS; vs const NUMBER OF USERS; 2 const FRIENDS; vs const NUMBER OF FRIENDS;
3. Leggibilità: Dare un nome poco comprensibile non aiuta il codice ad essere auto- esplicativo; String 1blFname; vs String label first name;
4. Abbreviazioni: E importante saper abbreviare i nomi che diamo alle entità nel codice. Se dobbiamo assegnare il nome ad un bottone; first btn anziché first button

Tipi di denominazione

Tipi di denominazione: Gli sviluppatori e i programmatori hanno definito delle vere e proprie convenzioni (Case-Notation) da adottare per le entità all'interno del codice. Queste sono:

1. Camel Case: In questa notazione si inizia a scrivere il nome dell'entità con la lettera minuscola, se però l'entità è composta da più parole, le successive inizieranno con la lettera maiuscola; firstName oppure countStudents ).
2. Snake Case: Si parte con la lettera minuscola, ma se ci sono più parole che danno il nome all'entità, le successive saranno precedute da un trattino basso; first name oppure compute_mean () .
3. Pascal Case: si differenzia dai precedenti perché la prima lettera è già maiuscola. Qualsiasi sia l'entità da definire, la prima lettera sarà sempre maiuscola; FirstName, ReverseName
4. Kebab Case: Si tratta della notazione meno utilizzata all'interno dei linguaggi di programmazione. Prevede la presenza di un trattino, tra la prima parola e le successive, anziché del trattino basso come visto nella Snake Case. first-name oppure compute-mean

Esempi di Case Notation

Esempi di Case Notation int sum; // nome semplice float degree_to_radiants; // nome composto string s; // la classe std: : string void do_something(); // il nome di una funzione int sum; nome semplice float degreeToRadiants; // nome composto void doSomething(); // il nome di una funzione / / Convenzione Pascal Case int Sum; nome semplice float DegreeToRadiants; // nome composto void DoSomething(); // il nome di una funzioneA space between parameters No space between the function name and parentheses between the parentheses and the parameter Curly brace { on the same line, after a space Spaces around operators Indentation 2 spaces function pow(x, n) { let result = 1; 12 A space after for/if/while ... for (let i = 0; i < n; i++) { result *= x; } A semicolon ; is mandatory return result; } A space between arguments An empty line between logical blocks let x = prompt ("x?", ""); let n = prompt("n?", ""); €> Lines are not very long if (n < 0) { alert(`Power ${n} is not supported, please enter a non-negative integer number'); } else { alert( pow(x, n) ); } } else { without a line break Spaces around a nested call

Esercizio: Correggere l'uso sbagliato del «Naming Convention»

Esercizio: Correggere l'uso sbagliato del «Naming Convention» #include using namespace std; int a, b, c; void fn1(int x, int y) { a = x + y; Y void fn2(int input_a, int input_b) { b = input_a - input_b; int main( ) { int num1, num2; cout << "Enter the first number: "; cin >> num1; cout << "Enter the second number: "; cin >> num2; fn1(num1, num2) ; fn2(num1, num2) ; c = a * b; cout << "Result: " << c << endl; return 0; Y

Esercizio: Correggere l'uso sbagliato del «Camel Case»

Esercizio: Correggere l'uso sbagliato del «Camel Case» #include using namespace std; int badFunctionExample(int input_Value) { int some_variable = 5; int AnotherVariable = 10; int result = some_variable + AnotherVariable + input_Value; return result; } int main() { int inputNumber; cout << "Enter a number: "; cin >> inputNumber; int outputResult = badFunctionExample( inputNumber ) ; cout << "Result: " << outputResult << endl; return 0; }

Esercizio: Correggere l'uso sbagliato del «Snake Case»

Esercizio: Correggere l'uso sbagliato del «Snake Case» #include using namespace std; int Calculate_Sum(int FirstNumber, int SecondNumber) { int someNumber = 5; int AnotherNumber = 10; int Result = someNumber + AnotherNumber + FirstNumber + SecondNumber; return Result; } int main() { int input1, input2; cout << "Enter the first number: "; cin >> input1; cout << "Enter the second number: "; cin >> input2; int TotalResult = Calculate_Sum(input1, input2) ; cout << "Total Result: " << TotalResult << endl; return 0; }

Ambienti di sviluppo integrati (IDE)

Ambienti di sviluppo integrati (IDE = Integrated Development Environment) Anche se è possibile scrivere un programma utilizzando un comune editor di testo è sempre preferibile usare un IDE. Ciò facilita e rende più rapido lo sviluppo di codice. Un IDE di base comprende sempre:

• Un editor avanzato (evidenziazione mediante colori diversi delle parole chiave, identificatori, costanti, ecc .; suggerimenti per il completamento delle righe, ecc.)
• Un compilatore integrato con l'editor (per i linguaggi compilati è compreso anche il linker)
• Un debugger, che consente l'esecuzione controllata del codice. E' infatti possibile inserire nel codice dei break-point. Quando si esegue il debug l'esecuzione si interrompe in corrispondenza del break- point, prima di eseguire l'istruzione. E' possibile a questo punto ispezionare il valore delle variabili.

Altri componenti in un IDE

Altri componenti che possono essere presenti in un IDE

• Un performance profiler
• Un analizzatore di code-coverage
• Un editor visuale
• Un editor UML
• Un sistema di controllo versioni (VCS)

Diritto d'autore e licenze software

Diritto d'autore e licenze software Nella UE l'unico strumento giuridico di protezione del software è il copyright, cioè il diritto d'autore. Non è prevista la brevettabilità del software. Uno sviluppatore di software può avere due esigenze:

• definire le modalità con cui il software realizzato può essere usato dagli utenti / acquirenti
• conoscere le modalità con cui può utilizzare nel proprio programma parti di codice sviluppati da altri programmatori Il produttore di un software può concedere agli utenti / acquirenti l'uso del solo codice eseguibile oppure anche il codice sorgente. In quest'ultimo caso chi acquisisce il prodotto lo potrà modificare o usare per sviluppare altri prodotti.

Concessione del codice eseguibile

Se si concede il solo codice eseguibile (gratuitamente o dietro compenso) si definisce un contratto d'uso, chiamato EULA (End User Licence Agreement), che l'utente deve accettare se vuole utilizzare il programma. La concessione del solo codice eseguibile è la modalità tradizionale e più diffusa di distribuzione dei programmi commerciali a pagamento. L'azienda o il programmatore non rende disponibile in questi casi il sorgente del proprio prodotto. Anche molti programmi freeware o shareware sono rilasciati solo come eseguibili. In alternativa esistono i cosiddetti programmi open source. In questi casi viene reso disponibile il codice sorgente del programma.

Licenze Open Source

Quando si fornisce il codice sorgente di un programma si parla di Open Source. Lo scopo è quello di favorire il riutilizzo del codice vincolandolo però al rispetto di alcune regole stabilite da un'apposita licenza d'uso. In generale una licenza open source cosa prevede?

• regole rigide sulla distribuzione di codice derivato: SI
• disponibilità del codice sorgente: SI
• divieto di produrre/vendere codice derivato: NO (purchè si rispettino i termini della licenza)
• possibilità di usare il codice in modo totalmente libero: NO
• obbligo di gratuità del programma: NO

Tipi di licenze open source

I principali tipi di licenze open source sono due:

• GPL: General Public Licence (è la licenza open source più nota, tipica di Linux e di molti altri prodotti oggi molto diffusi)
• BSD: Berkeley Software Distribution (licenza utilizzata per la versione di UNIX creata all'università di Berkeley) Nessuna licenza open source impone che il software rilasciato debba essere gratuito, anche se di fatto molti prodotti con licenza open-source sono distribuiti gratuitamente.