<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Software Release Practice HOWTO: Buone regole di sviluppo</TITLE> <LINK HREF="Software-Release-Practice-HOWTO-4.html" REL=next> <LINK HREF="Software-Release-Practice-HOWTO-2.html" REL=previous> <LINK HREF="Software-Release-Practice-HOWTO.html#toc3" REL=contents> </HEAD> <BODY> <A HREF="Software-Release-Practice-HOWTO-4.html">Avanti</A> <A HREF="Software-Release-Practice-HOWTO-2.html">Indietro</A> <A HREF="Software-Release-Practice-HOWTO.html#toc3">Indice</A> <HR> <H2><A NAME="s3">3. Buone regole di sviluppo</A></H2> <P>La maggior parte di queste regole sono volte ad assicurare la portabilità, non solo verso sistemi Linux ma ugualmente verso altri sistemi Unix. Essere portabile verso altri sistemi Unix non è solo un segno di professionalità e cortesia del programmatore, ma anche un'assicurazione preziosa contro eventuali futuri cambiamenti in Linux stesso. <P>Inoltre, altre persone <EM>cercheranno</EM> di compilare il loro codice su sistemi non-Linux; con la portabilità si ridurrà il numero di persone perplesse che invieranno fastidiosissime e-mail. <P> <H2><A NAME="ss3.1">3.1 Scrivere in puro ANSI C o in un linguaggio portabile</A> </H2> <P>Per la portabilità e la stabilità, si dovrebbe scrivere in ANSI C o in un altro linguaggio che sia garantito come portabile in quanto abbia un'implementazione multi-piattaforma. <P>Linguaggi di questo tipo includono Python, Perl, Tcl ed Emacs Lisp. Vecchi, semplici linguaggi shell non sono qualificati; ci sono troppe differenti implementazioni con sottili idiosincrasie, e l'ambiente shell è soggetto a interruzioni dovute alle configurazioni dell'utente come, ad esempio, quelle degli alias delle shell. <P>Java promette bene come linguaggio portabile, ma le implementazioni disponibili per Linux sono appena abbozzate e scarsamente integrate con Linux. La scelta di Java è per ora il minore dei mali, sebbene possa divenire più popolare con il tempo. <P> <P> <H2><A NAME="ss3.2">3.2 Seguire le buone regole della portabilità del linguaggio C</A> </H2> <P>Se si scrive in C, si è liberi di usare pienamente le caratteristiche ANSI -- prototipi di funzioni inclusi, che aiuteranno a individuare le inconsistenze tra i diversi moduli. I compilatori in vecchio stile K&R sono superati. <P>D'altra parte non si presupponga che alcune caratteristiche specifiche del GCC come l'opzione '-pipe' o le funzioni nidificate siano disponibili. Queste si torceranno contro a chiunque faccia un porting verso sistemi non-Linux o non-GCC. <P> <H2><A NAME="ss3.3">3.3 Utilizzare autoconf/ automake/ autoheader</A> </H2> <P>Se si scrive in C, usare autoconf/automake/autoheader per risolvere problemi di portabilità, sondare la configurazione del sistema, e confezionare i makefile. Chi installa dai sorgenti si aspetta, giustamente, di poter digitare "configure; make" e ottenere una struttura pulita. <P> <H2><A NAME="ss3.4">3.4 Controllare lo stato del codice prima di rilasciarlo</A> </H2> <P>Se si scrive in C, fare un test con '-Wall' ed eliminare gli errori almeno una volta prima di ciascuna release. Questo blocca un numero sorprendente di errori. Per una totale completezza si compili anche con '-pedantic'. <P>Se si scrive in Perl, controllare il codice con 'perl -c', 'perl -w', e 'perl -T' prima di ciascuna release (si veda la documentazione Perl). <P> <HR> <A HREF="Software-Release-Practice-HOWTO-4.html">Avanti</A> <A HREF="Software-Release-Practice-HOWTO-2.html">Indietro</A> <A HREF="Software-Release-Practice-HOWTO.html#toc3">Indice</A> </BODY> </HTML>
