Know How to Use Command-Line Tools
Carroll Robinson
TODAY, MANY SOFTWARE DEVELOPMENT TOOLS are packaged in the form of integrated development environments (IDEs). Microsoft’s Visual Studio and the open source Eclipse are two popular examples, though there are many oth- ers. There is a lot to like about IDEs. Not only are they easy to use, but they also relieve the programmer of thinking about a lot of little details involving the build process.
Ease of use, however, has its downside. Typically, when a tool is easy to use, it’s because the tool is making decisions for you and doing a lot of things auto- matically, behind the scenes. Thus, if an IDE is the only programming envi- ronment that you ever use, you may never fully understand what your tools are actually doing. You click a button, some magic occurs, and an executable file appears in the project folder.
By working with command-line build tools, you will learn a lot more about what the tools are doing when your project is being built. Writing your own make files will help you to understand all of the steps (compiling, assembling, linking, etc.) that go into building an executable file. Experimenting with the many command-line options for these tools is a valuable educational expe- rience as well. To get started with using command-line build tools, you can use open source command-line tools such as GCC, or you can use the ones supplied with your proprietary IDE. After all, a well-designed IDE is just a graphical frontend to a set of command-line tools.
??86 97 Things Every Programmer Should Know
?
???????????????In addition to improving your understanding of the build process, there are some tasks that can be performed more easily or more efficiently with command-line tools than with an IDE. For example, the search and replace capabilities pro- vided by the grep and sed utilities are often more powerful than those found in IDEs. Command-line tools inherently support scripting, which allows for the automation of tasks such as producing scheduled daily builds, creating multiple versions of a project, and running test suites. In an IDE, this kind of automation may be more difficult (if not impossible) to do, as build options are usually specified using GUI dialog boxes and the build process is invoked with a mouse click. If you never step outside of the IDE, you may not even realize that these kinds of automated tasks are possible.
But wait. Doesn’t the IDE exist to make development easier and to improve the programmer’s productivity? Well, yes. The suggestion presented here is not that you should stop using IDEs. The suggestion is that you should “look under the hood” and understand what your IDE is doing for you. The best way to do that is to learn to use command-line tools. Then, when you go back to using your IDE, you’ll have a much better understanding of what it is doing for you and how you can control the build process. On the other hand, once you master the use of command-line tools and experience the power and flexibility that they offer, you may find that you prefer the command line over the IDE.