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