If you’re new to Linux programming, then you might be interested in considering these aspects before you start your wonderful journey. Especially if you’ve programmed in Windows, you might want to change some of your ideas, so that you minimize the “culture” shock you experience when you encounter completely different ideas and ways of thinking.
Here are some of my tips, based on common questions asked in forums about Linux programming especially from experienced Windows programmers.
Evaluate every available alternative
Unlike the unified Windows API which provides the Windows programmer with a single method of achieving a certain objective, Linux provides a variety of ways to achieve the same objective. For instance there are a variety of GUI abstraction toolkits, the major ones being QT and GTK to write GUI programs. Again, you need not necessarily choose C or C++. There are many choices for programming including basic shell scripting, Perl, Python and PHP. So do not always have a fixed idea that you need to learn the “hard” way. In fact, you might be surprised to discover the power and elegance of scripting.
Do not be overwhelmed by choices. Just be aware of all of them and pick the tools and techniques that you’re most comfortable with.
IDEs are not necessarily more productive
Programmers who’ve used Microsoft Visual Studio extensively to do their development might find it uncomfortable to adapt to Linux’s way of doing things. While there are some pretty decent IDEs in Linux including Kdevelop, anjuta and Eclipse, you might actually find that using a text editor and creating a make file to be a better idea in the long run. Particularly when you are developing Free Software applications, you might not want to tie down development to a particular platform or IDE considering that your code will be shared and other programmers might also be contributing to your project. While IDEs are not always bad, you might find developing smaller projects using a simple text editor and a makefile a better idea.
Do not look for distribution-specific features
It might surprise many Windows programmers to know that you can practically make no assumptions about a default Linux configuration on the end user’s machine. Different distros use different configuration file locations and settings. Unless you’re writing a system configuration utility for a particular distro, try and avoid distro-specific assumptions. Also never force users to run as “root” unless your application’s sole purpose is to modify system specific settings.
Do NOT modify or attempt to modify system files
Apart from being bad programming etiquette,
- You cannot assume that a certain system file exists on the end user’s machine (because of distribution-specific differences).
- You simply cannot modify system files as a “normal” user and you cannot expect a normal productivity app to be run as “root.”
In most cases, you will find you hardly have any good reason to touch system specific files.
Be consistent visually
GUI programmers, especially GTK and QT programmers, need to understand that these libraries are heavily themeable (meaning that the end-user can modify the visual appearance of GUIs in almost any way possible - including fonts, colours and the widget appearance). Therefore, avoid using specific fonts or colours in your GUIs. You don’t need them. Do not force your end users to install any particular font on their system. Leave your application’s visual rendering entirely to the GUI library that you use. Unless you’re writing a word processor you might hardly ever need to directly handle fonts in your application’s code.
Be prepared to do some research
Linux does not come with an MSDN-like tool to provide you documentation for every single programming tool or API available out there. It’s simply not practical because Linux is not developed by a single company. In most cases if you’re using third-party libraries, you will be able to find documentation (either downloadable or online) on the official website of that particular library’s maintainer. Also be aware that quite a few libraries come with incomplete documentation or none at all.
You might have to look for sample code or even at header files to learn more about a particular library. Fortunately you might not encounter this situation in the case of most popular third-party libraries, but it’s better to be prepared nevertheless.
Do not package dependencies
When you’re creating a “distributable package” do not include dependencies along with your tarball. Just include the source and provide compiling instructions (the more generic, the better). Also mention the required dependencies in your README or INSTALL files and in your website. Since most Linux distributions have their own package management systems (and if you’re application is good enough, it might even be included in the official package repository), you should leave the dependency handling either to the end user who compiles your program manually or to the distribution package maintainer who ships your application as part of his package. Since every Linux distribution has a different way to manage dependencies, do not interfere with it by creating an “installation” routine that tries to be smart and installs other libraries.
Apart from creating versioning problems, it’s simply tedious and cumbersome to include dependencies with the program. Also try and keep the dependencies to a minimum, particularly if your program tends to use exotic third-party libraries.
Even if you’re not releasing your program as Free Software, try and keep the packaging to a minimum and provide instructions to the user on dependencies.
I hope this has been of use to you as a newbie to Linux programming. Happy programming!
From:
http://hari.literaryforums.org/2006/12/11/basic-tips-for-linux-programming/
