This is the last installment of the series exploring the components of a typical development environment. You may want to read Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, and Part 8 before reading this one.
This is a special post, not only because it ends the series, but because it covers a tool which integrates every single component in the toolchain to try and make our work easier when developing.
The Integrated Development Environment
These are also known as IDEs, and will be reffered as such for the rest of this article.
The primary task of the IDEs is to make every piece of software at our disposal work together to make our software development easier. They usually provide unform front ends to all of our tools; so you may see that your IDE has a built-in text editor, a command to compile the code, a debugger and profiler front end, and builds static code analysis feedback right into the text editor for ease of action. Furthermore, by knowing about the programming language and tools you’re using, the file and directory structure used by the IDE is thought to make you see the important things, and the unimportant not at all.
IDEs can get a bad rap because, by automating so much and providing front ends we can’t easily see through, they can hamper the learning process of the toolchain we depend on to work, creating habits that render us helpless if we stumble upon a peculiar situation that the IDE makers didn’t cover.
Another not-so-fun fact of IDEs is that, because they’re complex and refined pieces of software, a beginner or intermediate developer doesn’t feel in reach of improving the tool. Indeed, it takes a very particular kind of developer to realize early on that changing much of what goes on in an IDE, however complex it may be, is not even close to wizardry. That’s thanks, in part to the developers of the environment themselves, who architect means for customization in the form of plugin, macro, module or other extension support.
Here’s a list of gratis IDEs. I’ll also link to starting points to customize said IDEs.
- Netbeans; here’s how to start writing plugins.
- Eclipse; here’s their plugin developer guide.
- Visual Studio Community; here’s their getting started for developing extensions.
Arguably emacs and vi can become IDEs, but to do that you need to set up some plugins. If you’ve the mindset to work on those, you are already extending them, although with third party code. Keep it up.
This wraps it up for the week and the series. I hope you’ve enjoyed this light walk among the tools that help us code. If you’ve enjoyed this, please consider subscribing.
Have a nice weekend.