Most software developers have a strong opinion about their preferred source code editor. Whether they go for a full-blown IDE like Eclipse, Visual Age, or JBuilder; the kitchen sink style of emacs; or the minimalist approach of vi, Notepad, and bbedit, they know what they like and they generally dislike the rest.
But some software development shops toss developer preference out the window and select a standard development environment that is made a requirement for all developers. This decision is usually made for reasons of consistency, but those reasons are seldom enumerated and often barely examined. It is assumed that everyone needs to be working with the same tools for everyone to work together.
There are many reasons to allow developers to use the development environment of their choice. The first is increased personal productivity. Good developers can write code in whatever setup you give them, but they are happier and will work faster in the editor they feel most comfortable with.
In addition, if a project has or will have a cross-platform execution requirement; allowing developers to work on their platform of choice can be very beneficial. Of course, a testing team will be testing on all supported platforms, but developers are the first line of defense against newly added bugs. When you've got developers on multiple platforms, those bugs can be found earlier.
Another principle reason for supporting IDE diversity within a project is a desire to gain help from external developers. This is especially relevant to open source projects, where new developers join out of interest and donate their effort. A restrictive developer environment policy can keep many would-be helpers on the sidelines. Although corporate projects are less likely to accept work from whoever cares to help, good development environment portability can help in the case of source licensing.
Lowest common denominator
The real trick in finding a workable lowest common denominator for a friendly development environment is determining a baseline. Developers will use the advanced features offered by their selected editor setup, but so long as everyone is able to access and compile the code and commit changes, you've got a workable baseline. Making these basic functions available to all but the most obscure editing environments requires little more than a conscious effort to do so when selecting initial tool and storage format decisions.
Which source code repository to use for a project is one of the first and most important decisions to make when starting a project. The source control choice affects which editors will be able to work with the code and which platforms will be able to access the repository. Since few source control tools have import and export capabilities that include support for full histories, your source control decision can be with you for a long time.
The big players in the source control arena are Microsoft Visual Source Safe, Clear Case, Perforce, and Concurrent Versions System (CVS). Each has its supporters and detractors, but the real question is one of portability—both platform availability and storage formats. Up until recently, IBM's Visual Age for Java versioned code at the method level, which made editing code with anything other than Visual Age almost an impossibility. IBM is eclipsing its Visual Age offering and its new tools that use files as code containers.
Operating system portability among the listed source control systems is less uniform than their code containers. Visual Source Safe runs well only on Windows, though third-party tools for interacting with it do exist for other platforms. CVS, Clear Case, and Perforce all have versions that run on Windows, Linux, and Mac OS X but with various levels of functionality. Among them all, CVS finds the greatest support on all platforms and is probably the best choice, as it is most widely supported by various editing tools.
Some projects have wonderfully explicit coding standards covering everything from brace placement to white space composition. Many projects follow the pushiest person's lead on matters of style. However, a few of the decisions actually affect code editing, with white space being foremost among them. The width of a tab varies depending on whose editor you ask. A properly indented file in one editor can looked skewed in another. Often, tab width, shift width, and indent settings can be adjusted to account for these differences, but far and away the easiest solution is to require that tabs be saved as spaces. A space is the same width on every system, and most any modern editor can convert tabs to spaces when editing.
Line endings are another issue that cross-platform projects must deal with. Windows systems prefer two-byte line endings with a carriage return followed by a line feed. UNIX systems use a single line feed, while some Mac systems use just a carriage return. Again, most modern editors are able to recognize a line ending, edit it, and save out any of the possible formats. The best option when deciding which editor to standardize on is probably the system your source control server is running on. Files are checked for differences on that machine and native line endings help the process. If line endings are a problem, consider using a check-in/checkout filter script on your source control system to automatically convert files to the appropriate style.
Choosing which system to use for compilation is one of the stickiest decisions. Many IDEs have built-in compilation features that use proprietary project description files, which are all but unusable in other editors. Some IDEs simply leverage third-party build tools, such as Eclipse's use of ant. Many editors offer no build capabilities at all, instead relying on developers to drop to the command line for a build. With options like these, the choice should again be guided by the lowest common denominator principle. Make your build system something that works in as many places as possible.
A Java project normally means ant. Many of the popular IDEs have ant support, and ant has support for the most popular source control systems. For non-Java projects, makefiles with high portability are the best bet.
Make your choice
Heterogeneous build environments don't have to be an organizational nightmare to project managers. With a little forethought, you can have every developer working in whichever environment he or she feels most productive in without sacrificing team cohesiveness. Indeed, the diversity of a development team can reduce cross-platform support-related bugs and can make future project transitions less painful.