3. Buone regole di sviluppo

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.

Inoltre, altre persone cercheranno di compilare il loro codice su sistemi non-Linux; con la portabilità si ridurrà il numero di persone perplesse che invieranno fastidiosissime e-mail.

3.1 Scrivere in puro ANSI C o in un linguaggio portabile

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.

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.

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.

3.2 Seguire le buone regole della portabilità del linguaggio C

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.

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.

3.3 Utilizzare autoconf/ automake/ autoheader

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.

3.4 Controllare lo stato del codice prima di rilasciarlo

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'.

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).

Hosting by: hurra.com
Generated: 2007-01-26 17:56:18