A properly configured text editor is crucial to the quality of source code and the productivity of programmer. The selection of text editor is open-ended, but there are a few essential settings that every professional should do.
Convert tabs to spaces
Tabs vs spaces can sometimes lead to a debate as hot as vim vs emacs. While either is fine as long as their usage is consistent, we tend to love spaces in practice, because they are explicit in width. Remember why we love Python at Studio theYANG?
An interesting evidence statistically learned is that programmers using spaces tend to earn more than those using tabs by 2.4 years of experience.
Of course, there are exceptions. Makefile actually uses tabs as a crucial syntax. This means if we ever need to work with such languages, it’s important to make sure this “untabify” functionality won’t kick in and break everything.
Single trailing newline, no trailing spaces
The POSIX standard defines a line by “a sequence of zero of more non-newline characters plus a terminating newline character.” A trailing newline in action simply makes it much easier to use UNIX tools to work with text files.
It is also a common style guide that any trailing spaces to end of line or newlines to end of file should be cleared to reduce the surprise of editing and facilitate collaboration. Remember, team work is the key to any modern software development.
Heads-up at maximum line length
A super long line is never agreeable. We most commonly don’t wrap text when editing code and horizontal scroll is almost always a horrible experience.
The official Python style guide, PEP 8, limits all lines to a maximum of 79 characters. Most Python teams elect 120 characters because we are more used to wider screens now (considering PEP 8 was posted in 2001). Working with GitHub, a commit message exceeding 80 characters a line risks a horizontal scroll on web browser.
We should elect to the text editors that can support multiple maximum line length rulers to remind ourselves when editing. On the other hand, there is no need to enforce a wrap on lines exceeding the limit as there can be legit reasons.
Code linter integration
Today we have cheap and fast hardware, which is a great incentive to integrate code linting during editing process.
In-editor code lint often finds and helps eliminate syntax and reference errors at an early stage, streamlining the development and test.
Some editors can automatically find and apply project’s local linter configurations (like .flake8 file for Python), which is a big plus.
Web programmers: check for multi-mode support
Web programming has been much advanced in the past decade, kind of moving from assembly to compilable languages. Nowadays, many front-end developers work with multi-mode source code, like React JSX and Vue component file.
Thus, it is very important to experiment if the text editor is capable of doing it nicely and extensibly, as technology is advancing so fast.
Environmental variables
The last thing is to ensure if it is correctly hooked up with the console:
- Is there a short command for easy access to the editor?
- Does the command accept an argument to open a file or directory?
- Is the command blocking or non-blocking?
- Is it the default editor when running
git commit,git rebase, etc.? - Is it correctly blocking when used as default editor during
git commit, for example? - If using cygwin on Windows, does the command correctly find out the path to the file?
Backup
Last but not least, remember to backup your editor settings. It is even better to make a git repo to be synchronized and shared.
Conclusion
Again, tooling is increasingly important in software development nowadays, and text editor is absolutely the most essential one for programmers. It is always worth to keep it tuned up and reevaluate periodically with your workflow. Happy coding!
Studio theYANG 