What is an Integrated Development Environment (IDE)?

This is part of a larger series known as “How To Program Anything: Core Rulebook

Preface

The process of software development involves a lot of steps and scaffolding to build a final product.  Often times the complexity of the process depends on the size of your project.  A single file C program for instance is pretty straightforward, you write the program, and then run it through the compiler and you’re done.  But what happens when you the program takes up five files, or fifty files?  Do you run all fifty through the compiler at the command prompt by hand, and then do the same with the linker?  To conquer this issue programmers have come up with various methods and programs to automate the build process of a computer program.  Of course all of these tools are dependent upon what programming language you are using, and what requirements you are trying to meet.

But there are other aspects to software development besides building the final program file.  What about testing the software in a debugger, or as larger projects tend to do, include what is called unit testing in the build process.  These are programs built to interact with the main code base and run it through a battery of tests to make sure its working as expected and that some bug hasn’t crept into the code unexpectedly.

And yet, there’s still more, what about version control?  This is a suite of software and tools that make it so that you can automatically record all the changes you make over time to every file in the project, and in that way if you need to you can “roll back” whatever changes you might’ve made if necessary.  It is also helpful because multiple programmers can theoretically work on the project at the same time and merge in all their changes to the central repository.  Version control gives us a record/backup of the project so that in many ways it’s safe from being deleted or messed up.

What if you’re developing a program that uses a graphical user interface (GUI)?  You could specify all the elements and everything in the program by hand, either hard coding it (that’s where the information is carefully stuck in the code itself) into the program, or writing some kind of formatting file yourself.  But wouldn’t it be nice if there was a tool you could use to build your user interface and “glue” it to your code?  There should be a program for that.

You can approach the development of a software project many ways, and one of those ways is to use barebone tools and master various separate command line tools such as vi (a text editor), GCC (a C compiler), and make (a build process tool).  There’s nothing wrong with this, and many programmers use such bare bone tools successfully, but for me, remembering obscure shell commands, program inputs, and the inability to obtain point’n’click text editing functionality (not to mention code and type hinting, see below) eats too much into the time I could be producing code.

This is where an integrated development environment, otherwise known as an IDE, can come in for the rescue.  An IDE is singular program, or sometimes a set of programs, all with a consistent user interface that gives you tools, generally in a GUI format, that ties a lot of the separate components of software development together for you.  An IDE usually provides at the minimum tools for writing, modifying, and compiling programs, and some include mechanisms for packaging the final program into an application, and a real-time debugger, for making sense of a running program.  However, many IDEs go beyond that, and provide advanced text editing capabilities with code hinting (where the IDE analyzes your code and brings up relevant information about what you’re typing while you’re typing it), version control interfaces to ease the user experience with such systems, abstract code viewers such as class and object diagrams (classes and objects will be covered in Programming Crash Course Part 2) for object-oriented programming (OOP).  Many IDEs include the ability to lay out a graphical user interface visually and tie it to your code (a mild form of visual programming), and more.

The Aim of the IDE: Productivity

The idea behind an IDE is that it can handle the configurations required to make separate modular development utilities work together, and in so doing present the capabilities of these modules as one giant cohesive program.  The idea is that in many cases the interface and methods of the IDE are easier to learn and understand than all the messy scaffolding you’d have to do yourself to achieve the same thing.

But once those that process and tools are dealt with, that’s where an IDE can really shine for it can go further.  One area that can be achieved by plug-ins to some text editors, but is basically an automatic given for any IDE is syntax highlighting.  This is where the various keywords and constructions of a given programming language are actually written out in different colors so they are easy to read and spot.  When all your code is one color, it’s like a wall of text and your eye doesn’t necessarily know how to parse it apart very well.  But when keywords are highlighted say in blue, the commands and such stand out, allowing you to focus on where and what the commands are inside that wall of text.

It is possible for the IDE, and most all IDEs do this now, to parse all your code as you import it, and as you write it, to check for errors before you even compile, and even provide you information about what you’re typing.  This is known as code hinting.  For example, if I define a function in one file somewhere else, and the IDE parses that file for information, as I type in a call to that function elsewhere the IDE can pull up the function definition and the comments I attached to it, so I can see how I constructed it and what arguments it takes without having to re-open the other file.

Some IDEs even come with what are known as refactoring tools. These are tools that allow you to rename pieces of code or do other code transforms, and have that information reflected elsewhere in the same file or elsewhere in the code.  Refactoring is an art in and of itself that involves re-tooling a program or library of code to either operate better, or sometimes even fit another purpose.

Many IDEs dedicated to particular programming languages, such as C or Python, come with built-in graphical debuggers, which is a topic I’m going to cover in another article.  These debuggers let you basically see what’s happening with your code and variables in a step by step manner so that you can track down bugs, particularly ones where you don’t understand where they are occurring. I’ve often found running a program through a debugger just to see where the code generally goes step by step helps me understand the construction of a suite of code as well.  I’ve learned many an aspect of a library by doing just this.

How Did IDEs Evolve?

In the early days of programming, programs were written out using flowcharts and other designs and then either switched into a machine the size of a room, or punched on cards and inputted into the machine which would then sometimes perform a compilation step, sometimes the compilation step had to be done by hand.  When computers were finally hooked up to some kind of display device, with a general purpose input tool attached, like a keyboard, basically when a computer could have a user interface, is when IDEs were born.

The first IDEs relied on what was possible on a “terminal” or “console” screen, which at the time was mostly text.  You could do some pretty amazing stuff with just a console program, including menus and multiple “windows” or files open at the same time.  The important thing is that these first IDEs integrated file editing, management, compilation, debugging, and finally execution in one consistent program flow or block.  A popular IDE known as Emacs flourished in this kind of environment, though the author himself has never used it.

After the advent of the graphical user interface, such as with Operating Systems like Windows, the X Windowing Environment, and System 7+ for the Macintosh, IDEs were really able to gain more productivity enhancing power.  In one or several windows you could manage the files of a project, the compiler option, the code files in a color text editor, the output window and so on.  I remember my first IDE was QuickBASIC for my Macintosh IIsi.  I spend many an hour and many a long day trying my best to program games on that thing.

It became popular to start building IDEs with a plug-in type of architecture, where programmers could build and plug-in extensions into the IDE to get it to operate in various more specialized manners.  Eclipse became very popularly known for this kind of architecture, though it wasn’t exactly the first.  However, once it became popular many IDEs these days are built in similar veins.

IDEs have evolved over time to a pretty standard outline of components, and now are moving onto the web with the advent of such services as Cloud9.  Some IDEs are now being released as Software-as-a-Service packages, and they run in the cloud so to speak.

Advantages of Using an IDE

Every IDE is different and some come with features that others don’t.  Some IDEs are geared toward a particular niche, such as programming micro-controllers.  For example, the Keil IDE or CodeComposer for Texas Instrument micro-controllers has capabilities of interfacing with these devices built in so it becomes much easier to follow the somewhat obscure build process, including the downloading of the finished machine code onto the devices, that these types of instruments require.  If you are going to be programming a TI-RTOS micro-controller, then you’d be wise to pick one of these IDEs.

Some IDEs are specific to one language, or set of languages, such as the PHP or Python, and don’t have the build utilities required for a program written in C or C++.  However, they may come with package managers for those particular languages, something C and C++ don’t necessarily have.  Some IDEs are built with a particular runtime environment in mind, such as Apple’s XCode for building macOS applications (though it can do more), and iOS apps.  So if you were building a macOS application, you’d probably want to use XCode as an example.

The point here is that you can only get so far with a simple text editor (without syntax highlighting), a compiler, and a build process automation tool.  Duplicating some of the configurations these IDEs have already made for you often results in a mess of code that is obscure and difficult to understand, at least that’s been my experience.  I find it easier to learn how an IDE works so that I can utilize it to produce what I want, whether that’s a Python package, a node-webkit program, a C program on a microcontroller, or a macOS application.

The biggest advantage of using an IDE is productivity.  For instance on Cloud9 I have access to my files, my syntax-highlighted code-hinting text editor, a shell console in the bottom for a access to the machine, and a code explorer generated from what I type.  And in some instances a debugger, and this is all hosted and served through the web browser meaning I can pull it up from any device anywhere that has a browser.  That’s pretty productive!

Another advantage I’ve found with IDEs is that you can get plug-ins or extensions for them you can’t necessarily get with a plain text editor, such as an interface to Git (a version control program), or an interface to a database so that you can easily see the potential data you’re working with.  Or even, say, on Cloud9 the ability to have two programmers working on the same screen at the same time.  With web projects you can get an SFTP plugin that allows you to mirror your project on a testing server, and deploy to a production server.  These are all things beyond the scope of a simple text editor.

The Usual Layout of an IDE

For this section I’m going to use two IDEs I’ve been using lately, Komodo 10 (which I won as a prize from phpclasses.org) and Cloud9.  You’ll notice they have similar layouts, and indeed, even Eclipse and other IDEs have a pretty standard layout (until you mess with it).

Cloud9 Integrated Development Environment

The way I work, on the left hand side are my files.  In many IDEs these are the actual files, and/or sometimes code components that make up your project. As you can see here I have Map.php open in the editor (This is part of asherwunk/phabstractic and you can read more about the map here.)  Now in the editor, the middle of the screen, you can see my syntaxed highlighted code (well mostly a documentation comment).  Below this window is what I call the tool window, and here I have access to a shell terminal on the host machine (it’s all Ubuntu).  I also have access to an immediate JavaScript console, and some Apache PHP stuff on the right tab.  No on the far right, you’ll see that the IDE has parsed this file (map.php) and has given me an outline of the code I have input in.  Those are all the names of the methods (functions) that my Map class supports, and if I click on any one of them I jump straight to that definition in the file.  This may not look like much, but it’s a very powerful set-up all in one place. On my PHP and Python projects I use the console to install development dependencies (via Composer and else-wise), execute my git version control commands (already configured all up by Cloud9), and I also run my unit tests.  I can open multiple files from the left and they’ll be under different tabs, and I can set tabs up next to each other and see them side by side.

Komodo IDE 10

With Komodo, a commercial IDE for all sorts of development, you get a lot of bells and whistles.  Ad you can to the left side I have buttons for many things including unit testing, interactive shell, a code profiler (to test how fast your code runs), an HTTP inspector.  A little to the right, and you see my file manager and project manager.  The file manager contains all the files of a given project, and the project manager sets up Komodo with different configurations for different projects.  For example, chrahkiwriter was a JavaScript/HTML project, while gameofgods is actually my JavaScript/Python Hybrid PYGJS.  In the center is the good old text-editing window, with syntax highlighting, and such. If I opened another file another tab would appear.  Below that is the console, and you can see I have version control tools, syntax checking, console, unit testing, multiple file find and replacement things.  To the right, there can be more, such as a code inspector and outliner, but they’re closed right now.  To the right you can see a miniaturized version of th every file I’m working on.  It helps me keep track of where I am in the code.

Other Kinds of IDEs

Some IDEs are built specifically for what is known as visual programming, for example with the programming language Scratch.  Lego MindStorms has there own visual programming implementation as well for programming their simpler microcontroller blocks.  Or there are tools for several IDEs where you can layout the structure of a programming system using a modeling language such as Unifed Modeling Language (UML), whereupon the diagrams will be interpreted and the code generated to match the specifications.  Some IDEs assist in ways like these to aid in the software engineering stage of software development.

Another kind of IDE is a a Game Integrated Development Environment (GIDE).  This is a program which also encapsulates some sort of run time “game” engine where all the information being put into the system will run.  Unity is a very popular version of this kind of IDE.  You program the games in C# using MonoDevelop and attach them to objects in the system.  Pressing play runs the game simulation inside the Unity editor so you can see the results.  In this sense, not only does compilation happen in the IDE, but runtime testing as well.  Deployment becomes the final stage then in the sharing process.

Conclusion

I’m not personally huge on modifying or getting my IDE to do lots of bells and whistles, but simply having a central program and place to debug, test, compile, and write your code is very powerful for your productivity.  Add on that basic code inspection tools, error checking, syntax highlighting, file tracking, version control, and you got yourself a tool I’d use any day.

However, funny enough, I don’t know if I’d recommend you use an IDE right off the bat when you start learning to program.  Keeping the focus on a clean program, a simple execution, and actually having your hand in the compilation process can be a learning experience, but I can almost guarantee you; you start or get a programming project with 15+ files, a specialized build process with unit testing, tens of thousands of lines of code, you’ll definitely appreciate code-hinting and built-in version control.  I’m sure there are numerous plug-ins for various IDEs that I don’t even know about that can make programming a breeze.

This is part of a larger series known as “How To Program Anything: Core Rulebook

If you appreciate this article you might consider supporting my Patreon.

But if a monthly commitment is a bit much, I get it, you might consider buying me a coffee.

photo credit: Metal Sheets Limited 138 – Copper Worktop with Integrated Sink via photopin (license)

Liked it? Take a second to support kadar on Patreon!

kadar

I'm just a wunk, trying to enjoy life. I am a cofounder of http//originalpursuitssoc.com/ and I like computers, code, creativity, and friends.

You may also like...

Leave a Reply

%d bloggers like this: