RidgeRun Developer Manual - Editors
 | WORK IN PROGRESS. Please Contact RidgeRun OR email to support@ridgerun.com if you have any questions. |
| RidgeRun Developer Manual |
|---|
 |
| Coding Styles |
| Development Tools |
| Editors |
| Debugging Tools |
| Methodologies |
| Design Patterns |
| Testing |
| Build Systems |
| Contact Us |
Contents
Developer's IDE
The Integrated Development Environment (IDE) is probably the most fundamental tool of a developer. Similar to how a chef invests in a good set of knives or how a surgeon requires precision scalpels, the IDE can make a huge difference in the quality and efficiency of a programmer. Setting up these environments rarely is considered a waste, but an investment. A professional developer understands the importance of working with the right tools.
An IDE is set of tools integrated to make the development process more efficient. These are typically plug-ins, meaning that they may be independently installed, configured or removed by the user. The later allows the developer to customize it's environment according to his/her preferences (programmers are known to be proudly picky :)) Among these, the Code Editor (CE) is the core of the environment. Around it, several plug-ins add extra functionality such as integrations with version control system, debuggers, tests, static code analysis, etc...
Generally speaking, we recommend that every developer is fluent with, at least, two environments:
- Console based Code Editor
- Integrated Development Environment
Figure 1 shows an example of the two aforementioned environments.
- Figure 1. Example of development environments
Console based Editor (CE)
Integrated Development Environment (IDE)
Console Based Editor
A lightweight editor that opens within the terminal emulator. You'd typically use this for quick edits, or momentary remote editing. If a project will require you to remote edit as you primary (or very constantly) consider setting up a remote IDE instead.
Popular console editors include:
This is not your primary editor, however you should be fluent in it. Make sure you at least know your way around with:
- Search and replace
- Jump to line number
- Copy, cut and paste (without explicit use of the mouse)
- Several files in a single session (no need to close and re-open the editor)
Integrated Development Environment
The IDE is intended to be your primary development environment. It is expected that you invest time setting it appropriately, rarely an IDE is meant to be used out-of-the box. An environment properly configured speaks positively about the profesional maturity of the developer.
A list of popular IDEs (as per early 2020) include:
- Emacs and its variants
- VIM and its variants
- Visual Studio Code
- Atom
- Eclipse
- Geany
- Sublime
- Xcode
- Qt Creator
The choice and configuration of the IDE is a very personal one. Although RidgeRun understands and promotes this, we do have some expectations and recommendations on the final setup. The following sections detail these further.
IDE Features
| Feature | Availability |
|---|---|
| #Static Code Analysis | Indispensable |
| #Code Completion | Indispensable |
| #Code Navigation | Indispensable |
| #VCS Integration | Desired |
| #Debugger Integration | Desired |
| #Remote Editing | Desired |
| #Auto-Indenter | Desired |
Details of Features
These features are considered indispensable in every modern IDE. If your selection does not seem to have the ability to do these (which I doubt), you should consider a different alternative.
Static Code Analysis
Formally called linting or running a linter. A Linter is a tool that analyzes the source so that it complies with a set of user defined standards. For example, a linter would typically detect and notify flawed code regarding:
- Style (proper indentation and code structuring)
- Safety
- Portability
- Memory integrity
- Syntax errors
- Unintended side effects
- Undefined behavior
This analysis is normally done inspecting the code without actually executing it, hence the static in static code analysis. Although linters are standalone tools, they are integrated within editors to perform this checks on-the-fly. In other words you get instantaneous code feedback as you type. This is the desired behavior.
The following table summarizes the list of recommended linters for different languages. See our List of Code Linters for details on how these were selected.
| Language | Linter |
|---|---|
| C | cppcheck |
| C++ | cppcheck |
| Python | pylint |
Code Autocompletion
Modern IDE are framework aware. This means that, once the project is properly configured, the editor knows which framework you are using and is able to suggest interesting code completions as you type. For example, typical autocompletions include:
- Function/method names
- Struct/class members
- Constants
- Variables
While some IDEs may have a built in mechanism to do autocompletion, others rely on external tools to provide autocompletion. Among the most popular you may check:
Ideally, enabling the autocompletion will minimize the amount of time a developer spends retrieving the documentation. Again, this is a fundamental IDE feature.
Code navigation is an essential part of development and debugging. It refers to the ability to jump between symbol definition, declaration and usage throughout the project. This is specially useful when trying to understand the control and data flow of a complex project, for example.
Code navigation usually requires running an initial step within the project. Some IDEs will run this automatically, but some others (and according to the underlying tool being used) will require a manual preparation. This is usually fine. The benefits that code completion brings are worth it.
Again, some IDEs have this option built in. Others rely on external tools to achieve the navigation. Among the most popular you may check:
VCS Integration
Debugger Integration
Remote Editing
Auto-Indenter
