Today, many software development tools are delivered as integrated development environments (IDEs). Besides the two popular examples – Visual Studio from Microsoft and Eclipse from the open-source community – there are many others. A lot can be said in favor of IDEs. They are easy to use and they free the programmer from the need to delve into many minor details, including the build process.
However, ease of use has its downside. A tool is usually easy to use when it makes decisions for the programmer and automatically does a large amount of work behind the scenes. Therefore, if you only use an IDE as your programming environment, it is quite possible that you will never fully understand what your tools are actually doing. You press a button, magic happens, and an executable file appears in your project folder.
Working with command-line tools, you will learn much more about what your tools do during the project build. Creating your own makefiles will help you understand all the stages of building an executable file (compilation, assembly, linking, etc.). Experimenting with the numerous command-line options of these tools is a valuable and educational practice. You can start working with command-line build tools using open-source command-line tools like GCC, or those that come with your commercial IDE. After all, a well-designed IDE is just a graphical interface to a set of command-line tools.
This way, you will gain a better understanding of the build process. Moreover, certain tasks in the command line are performed more easily and efficiently than in an IDE. For example, the search and replace capabilities of utilities like grep and sed often exceed the similar functions of IDEs. Command-line tools are geared towards script-based task execution, which allows for automation, for example, of performing daily builds at a specified time, creating multiple versions of a project, and running test suites. In an IDE, such automation can be difficult (or even impossible) because build parameters are usually specified through GUI dialog boxes, and the build process is initiated with a mouse click. If you have never ventured beyond the IDE, you might not be aware of the possibility of automating such tasks.
Wait a minute. Don’t IDEs exist to facilitate development and increase programmer productivity? Well, that’s true. I’m not suggesting you stop using an IDE at all. You just need to look “under the hood” and understand what tasks the IDE is doing for you. And the best way to do this is to learn how to use command line tools. After that, when you return to your IDE, you will have a much better understanding of what it does for you and how you can manage the build process. On the other hand, having mastered the command line tools and recognized their power and flexibility, you might prefer using the command line instead of the IDE.