Die meisten derjenigen widmen sich der Gewährleistung der Portabilität, nicht nur über die verschiedenen Varianten von Linux hinweg sondern auch zu anderen Unixen. Portabel auf andere Unixen zu sein, ist nicht nur eine verdienstvolle Form von Professionalität und Höflichkeit gegenüber Entwicklern sondern auch eine wertvolle Versicherung gegenüber zukünftigen Änderungen innerhalb Linux selbst.
Zudem werden gewisse Personen versuchen deinen Code auf Linux-fremden Systemen zu kompilieren; Portabilität vermindert die ungeheuere Anzahl der nervenden, verdutzten Email Nachrichten, die du ansonsten erhalten würdest.
Es empfiehlt sich betreffend der Portabilität und Stabilität in ANSI C oder einer Scriptsprache, welche aufgrund nur einer "Quer"-Plattform Implementation garantiert portabel ist zu programmieren.
Scriptsprachen, die diesem Kriterium entsprechen, beinhaltet Python, Perl, Tcl, Emacs Lisp und PHP. Die schlichte, alte Shell erfüllt dieses Kriterium nicht; es existieren zuviele verschiedene Implementationen mit subtilen, persönlichen Eigenarten; zudem ist die Shell Umgebung ein potentielles Opfer der Zerrüttung durch Benützeranpassungen wie z.B. Shell-Aliase.
Java ist zwar in seinen Grundzügen eine portable Sprache, die Linux-verfügbaren Implementationen sind jedoch noch immer fehlerhaft und ausserdem schlecht in Linux integriert worden. Java ist noch immer eine wunde Wahl, obschon es populäreren Status erlangen wird sofern es gewisse Aspekte verbessern wird.
Lass dich weder mit proprietären Sprachen, Bibliotheken noch Code ein. Innerhalb der Open-Source Gemeinschaft wird dies als unzivilisiert bedacht. Open-Source Entwickler vertrauen nichts, von dem sie nicht den Sourcecode einsehen können.
Wenn du C programmierst sei ermutigt gänzlich alle ANSI Möglichkeiten auszureizen -- Funktionsprototypen beinhaltend, welche dir die Mühe betreffend der Evaluierung von "Quer"-Modul Inkonsistenzen erleichtern wird. Die altgedienten K&R Compiler sind längst Geschichte.
Im Gegensatz dazu nimm nicht an, dass GCC-spezifische Möglichkeiten wie die `-pipe' Option oder andere "eingenistete" Funktionen vorhanden sein werden. Diese werden früh genug Komplikationen verursachen, spätestens jedoch dann wenn jemand das Programm auf ein ein nicht-Linux, nicht-GCC kompatibles System portiert.
Sofern du C programmierst verwende autoconf/automake/autoheader, um portabilitätsspezifische Probleme zu eruieren. Teste Konfigurations Sondierung und passe deine Makedateien entsprechend an. Personen, die heute von Source auf kompilieren, erwarten, dass es möglich sein sollte anhand der Befehle "configure; make" einen klaren Build zu erhalten -- und diese Erwartung ist gerechtfertigt.
Sofern du C programmierst, führe einen test-compile mit -Wall aus und beseitige die Fehler zumindest einmal vor jeder Veröffentlichung einer neuen Version. Dies lässt eine Unmenge von Fehlern zutage kommen. Für wahrhaftige Gründlichkeit, kompiliere auch mit der Option -pedantic.
Für Python Projekte, ist der PyChecker ein nützliches Evaluierungsprogramm. Im haftet noch immer der Betastatus an, aber ungeachtet dessen erkennt es oftmals nichttriviale Fehler.
Und sofern du Perl programmierst, überprüfe deinen Code mit perl -c (und vielleicht auch mit -T, sofern anwendbar). Gebrauche überdies perl -w und 'use strict' religiös. (Siehe die Perl Dokumentation betreffend weiterführender Erläuterung)
Führe einen Rechtschreibungsprüfer aus. Wenn du Eindruck erweckst, dass du unfähig bist zu buchstabieren und dass dies schlimmer noch dich wenig bekümmert, wird man annehmen, dass dein Code ebenso unsorgfältig und fehlerhaft sein wird.