The code itself, the symbols and strings that eventually dictate the behavior of a machine, is one thing, but properly preparing it and executing it requires a dedicated venue. Your operating system’s standard text editor—TextEdit on Mac and Notepad on Windows—will really only get you so far before becoming a limiting factor. These stock tools are generally meant for writing text intended for human consumption and offer few of the even most basic coding features, including looking the part.
Unfortunately, the world of code editors is a complete zoo. Some editors are elaborate Photoshop-like behemoths offering platforms suitable for building vast software projects, while others are esoteric and minimal, rewarding only those with patience and willingness to cope with a steep learning curve. Some editors are suited for specific programming languages and platforms, like Swift and iOS, while others aim to be general but extensible. A few are completely meaningless beyond one specific language, while a small set of code editors become programming languages unto themselves. So, given all of the noise, where should one even start?
I think I can help. What follows is a field guide intended for those most likely to be asking the above question: the code curious, beginners, advancing novices.
1.0) SUPERCHARGED TEXT EDITORS: SUBLIME TEXT AND ATOM
For the type of coding described in the Hack This series, this is the ideal category of text editor. It’s dominated by Sublime Text and Atom. The latter is free, while the prior theoretically costs money but can be evaluated indefinitely as nagware (you should pay for it!). When you first open one of these editors, at first glance it may just seem like an iteration of TextEdit/Notepad with better colors. It’s when you start digging around in the menus that the depth and capabilities become clear.
For one thing, both come equipped out of the box with syntax highlighting for pretty much any programming language you’re likely to be interested in. This might seem kind of trivial when you’re starting out, but once you know a language a bit and what a script or program in that language should look like, highlighting becomes immensely valuable in making code readable. Eventually, monochrome code will just look wrong, like English written without paragraph breaks or punctuation.
Editors in this category are extensible via package systems. The package ecosystem for Sublime Text is vast, with installable packages offering new editor capabilities ranging from those enabling regular word processing (like word count and spell check), HTML templating engines (like Handlebars), Git integration, code quality tools, and well beyond. Whatever sort of coding you’re into, it’s possible to essentially build up your own ideal code editor via these third-party packages. Personally, I don’t take enough advantage.
2.0) IDES
In my early-days community college programming courses, I starting out writing code within the beast that is Visual Studio, Microsoft’s integrated development environment (IDE) geared toward developing full-on software for the .NET framework. Within Windows, this is the natural home for writing old-school PC software in C++, C, and C#. In school, this meant making things like prime number checkers, record collection organizers, and Colossal Cave Adventure clones.
IDEs are enormously powerful, and, unlike the aforementioned text editors, this power is flung at users out of the box. It can be intimidating. Most offer extensions for new programming languages and frameworks that essentially amount to new IDEs within IDEs. The Scala IDE, for example, is really a specialized version of the Java-centric Eclipse IDE (Scala is an extended version of Java). Similarly, Android Studio is really an extension of the more general Java IDE IntelliJ IDEA.
What drives me from a text editor like Sublime Text to a full-fledged IDE is usually organization and-or debugging. Sublime and Atom both offer the ability to manage multiple files and directories, but this just feels more natural in an IDE, particularly when things get really messy in contemporary web development, which demands extreme modularity and the inclusion of often many, many outside libraries.
When dealing with long, complicated programs, debugging becomes a far more involved process than just staring at a dozen lines of code for a few minutes until the error is magically revealed. Instead, it becomes neccessary to watch the code in action as it executes. This is what step-through debugging achieves. A debugger allows programmers to manually step through their code line by line as it executes, providing a means to observe side effects and state changes as they happen.
As such, bugs can be traced down to the lines where they occur, which is pretty neccessary when dealing with hundreds or tens of thousands of lines of code spread across many individual files. An IDE can allow programmers to even observe code execution at extreme low levels, including physical processor registers and memory addresses. Part of this low-level view is what’s known as code profiling, where precise performance statistics can be collected about a given section of code. Bugs are, after all, more than just program-sinking errors, but include system-draining inefficiencies. You could say these are algorithm-level bugs.
As far as IDEs go, you’ll find many arguments for the JetBrains family of software, including PyCharm for Python (above), WebStorm for JavaScript and website development, CLion for C and C++, and others. These are all highly worthy (but not free).
2.1) XCODE
Xcode is sort of its own class of IDE. This is where Apple pushes iOS development. It’s built for writing code in Swift and its predecessor language Objective-C, the languages of iOS, and comes with specialized tools for simulating and profiling Apple devices. Part of its appeal is an emphasis on visual coding. As far as IDEs go, it’s unusual in this friendliness to non-programmers. You can get pretty far in building an iOS app just through dragging and dropping. There’s no Windows version.
3.0) HARDCORE TEXT EDITORS: VIM AND EMACS
Vim is hard enough to describe, let alone use. On its face, it’s a hyperminimal text editor, a realm where even the mouse has no meaning and drop-down menus have yet to be invented. Menu actions instead are accomplished via text commands. Saving? That would be :w. Quitting without saving? :q!. Copy and pasting?
Glad you asked. Behold, the official Vim documentation: *04.6* Copying text
To copy text from one place to another, you could delete it, use “u” to undo the deletion and then “p” to put it somewhere else. There is an easier way: yanking. The “y” operator copies text into a register. Then a “p” command can be used to put it.
Yanking is just a Vim name for copying. The “c” letter was already used for the change operator, and “y” was still available. Calling this operator “yank” made it easier to remember to use the “y” key.
If that makes sense, then congrats, you understand Vim. Based on years of reading Vim-related answers on Stack Overflow, this understanding is a point of pride among Vim users, which is putting it mildly. I kinda-sorta understand Vim.
Vim (and Emacs, its traditional competitor) offer more than esotericism for its own sake. There’s immense power behind the maddening anti-interface (which is really a function of Vim and Emacs predating graphical operating systems and even PCs, generally). Interfacing with Vim is based entirely on keystrokes—even the cursor keys are shunned in favor of the h, j, k, and l keys—which winds up being really, really fast when you have the hang of it.
Consider that in a typical GUI environment most everything is accomplished by interrupting keyboard typing and interfacing with some menu element. Even if that element displayed front and center in a toolbar, the fingers are forced to leave and then return to the keyboard. In Vim, those same commands are achieved as a part of the same keyboard typing flow. That’s the key word: flow.
Vim is extremely customizable and constitutes a programming language in itself. Much as we might enter a Python command into a Python interpreter or a Bash command into the Bash interpreter, we interact with Vim by entering Vim commands onto the Vim command line. As with Python and Bash, we can collect those commands into scripts, which are referred to in Vim configuration files.
There’s a whole history here that I’ll save for another post, but Vi (Vim’s earlier incarnation) and Emacs are both now 40 years old and constitute the earliest text editors for any purpose, coding or otherwise. Both still come built into Unix-based operating systems, including OSX. Just type vim or emacs in the terminal.
So where should you write code? If you’re asking the question, the answer is probably Atom or Sublime Text. Both are simple out of the box but will grow with you. Eventually, you’ll be forced to pick something else up—like Rstudio for data analysis in the R language, or Xcode for app development—but when it comes to writing useful scripts for tasks like, say, webscraping or automating operating system tasks, you want a space that can offer features only when you need them and a space where you can focus on the code, not the environment.
Source:https://motherboard.vice.com/
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
