Integrated Development Environment (IDE) options
It's certainly possible to write and edit code without using a full-blown Integrated Development Environment (IDE). Ultimately, anything that can read and write text files of arbitrary types or with arbitrary file extensions is technically usable. Many IDEs, though, provide additional, development-centric capabilities that can save time and effort—sometimes a lot of time and effort. The trade-off is, generally, that the more features and functionality that any given IDE provides, the less lightweight it is, and the more complicated it can become. Finding one that every member of a development team can agree on can be difficult, or even painful there are downsides to most of them, and there may not be a single, obvious right choice. It's very subjective.
In looking at code editing and management tools, only real IDEs will be examined. As noted, text editors can be used to write code, and there are a fair few of them out there that recognize various language formats, including Python. However good they are (and there are some that are very good), if they don't provide at least one of the following functional capabilities, they won't be considered. It's just a matter of time until something in this list is needed and not available, and at a minimum, that eventuality will be distracting, and at worst, it could be a critical issue (though that seems unlikely). The feature set criteria are as follows:
Large-project support: A large project, for the purposes of discussion, involves the development of two or more distinct, installable Python packages that have different environmental requirements. An example might include a business_objects class library that's used by two separate packages such as an online_store and back_office that provide different functionality for different users. The best-case scenario for this would include the following :
- Support for different Python interpreters (possibly as individual virtual environments) in different package projects
- The ability to have and manage interproject references (in this example, the online_store and back_office packages would be able to have useful references to the business_objects library)
- Less important, but still highly useful, would be the ability to have multiple projects open and editable at the same time, so that as changes in one package project require corresponding changes in another, there's little or no context change needed by the developer making those changes
Refactoring support: Given a long enough period of time, it's inevitable that changes to a system's code without changing how it behaves from an external perspective is going to be necessary. That's a textbook definition of refactoring. Refactoring efforts tend to require, at a minimum, the ability to find and replace entity names in the code across multiple files, possibly across multiple libraries. At the more complex end of the range, refactoring can include the creation of new classes or members of classes to move functionality into a different location in the code, while maintaining the interface of the code.
Language exploration: The ability to examine code that's used by, but not a part of, a project is helpful, at least occasionally. This is more useful than it might sound, unless you are lucky enough to possess an eidetic memory, and thus never have to look up function signatures, module members and so on.
Code execution: The ability to actually run the code being worked on is immensely helpful during development. Having to drop out of an editor into a terminal in order to run code, to test changes to it, is a context change, and those are tedious at the least, and can actually be disruptive to the process under the right circumstances.
These items will be rated on the following scale, from best to worst:
- Superb
- Great
- Good
- Fair
- Mediocre
- Poor
- Terrible
Many IDEs have various bells and whistles functionality that helps, perhaps substantially, with the processes of writing or managing code, but isn't something that's really critical. Examples of these include the following:
- The ability to navigate to where a code entity is defined from someplace where it's being used
- Code completion and autosuggestion, which allows the developer to quickly and easily select from a list of entities based on the first few characters of an entity name that they've started typing
- Code coloration and presentation, which provides an easy-to-understand visual indication of what a given block of code is – comments, class, function and variable names, that sort of thing
These will also be rated on the same scale, but since they aren't critical functionality, they are presented merely as additional information items.
All of the following IDEs are available across all the major operating systems – Windows, Macintosh, and Linux (and probably most UNIX systems, for that matter) – so that, an important criteria for evaluating the IDE part of a development toolkit is moot across the three discussed.