Double Click Preferred

The code editor is the subject of an endless amount of discussions. I have to offer some advices about this situation.

1. You should not care too much about code editors, past a decent setup.
2. If you are motivated to dive into a code editor (like Emacs or Vim), you should probably go for it.
3. A programming language may be better handled out-of-the-box by some editors than others.
4. In a professional setting, the editor may have already be chosen for you: go with the flow.
5. Beware of the sirens Emacs & Vim as they are very foreign from the rest of editors, especially their key bindings.

1. The term itself tells you all: “code editors”.
   Not “JS editor” or “C editor” but “code editor”. The reality is close to this: all mainstream code editors give you the ability to code in all mainstream programming languages. Case in point: you can find people coding in a language with different editors. And the reverse too: people coding in different languages with the same editor. And all these people are just fine.
   This is because editing is a similar activity regardless of the language. Because programming is a lot about text and not much else. Because languages give textual rules and not much else. Conclusion: past a decent setup, you should not care too much about code editors.
2. But if you happen to be motivated to dive into one, I think you should go for it —Emacs and Vim being the most demanding but probably the most rewarding.
3. Still, a reason to care: a given programming language may be better handled out-of-the-box by some editors than others.
   If you want to code in Typescript/Javascript, consider using Visual Studio Code and if you want to code in Java, have a look at either Eclipse or IntelliJ. As for other programming languages, I only use them very occasionally and so I tend to default to Visual Studio Code.
4. Then, a reason not to care: in a professional setting, that choice may already be done for you. Unless you are ready to configure your editor a lot to keep using it, go with the flow. It cannot hurt to experience a different editor.

Lastly, the sirens: Emacs & Vim. Some people swear by them. They will rave at how flexible the editor is. And this is very true. Both editors are exceptionally flexible and no wonder: configuring them is programming. It is not difficult programming but it does mean that you have to learn a programming language (Emacs Lisp or Lua).

Again, if you are motivated, go for it: you will probably learn a lot. Just be aware that both editors are not useful nor in usable state out-of-the-box, by admissions of their very defenders.

But the real problem are the key bindings: both editors have their own way of doing things, Vim being even more alien to the rest of code editors than Emacs is. What you learn won't translate to any other editor. So, if you are an absolute beginner in programming, I would advise to ignore Emacs and Vim at first.

Here is what I mean by “decent setup”, with recommendations for Javascript. They are not only applicable to Visual Studio Code but I'm sure they work well with it.

(1): types are often indistinguishable from the programming language so you may not have a choice here.

(2): actually depends on the type system.

Encodings, fonts and end of lines. If your code editor cannot be configured on all these 3 things, ditch it. Period.
Pick UTF8 encoding, a monospace font meant for coding and set LF for the end of lines.

Your code editor must handle encodings, fonts and end of lines.

1. Encodings

   Pick UTF8. It is probably what your editor already uses, which makes sense as the majority of source files are encoded with UTF8 anyway, regardless of the programming language.

   Also note that UTF8 is the de-facto choice for web pages, database tables and all kind of text transmissions. It is safe to say that, when something is not encoded in UTF8, it is either the result of a deliberate choice, or a historical setup that dates from years ago and which is too complicate to change.

   But what is an encoding? It is a way to make sense of binary data. Binary data are just “0s & 1s”. Just like we assign a meaning to a sequence of letters (i.e. to a word), we can define what each specific sequence of “0s & 1s” means. The computer then uses the definitions to produce some information from the binary data.

   For instance, if the sequences are tied to colors, then the computer can display an image out of some binary data. If the sequences are tied to sounds, then the computer can play some music. And if the sequences are tied to letters, then the computer can show us some text.

   When some binary data represent image or sound, we talk of a “format”. When they represent text, we talk of an “encoding”.

   To preserve the meaning of the binary data, we must stick to the definitions of what each sequence of “0s & 1s” means, when loading the data and when saving it back. Every software we use must stick to the definitions. And so it is for every person to whom we send some data. With the wrong definitions, we reconstruct a different meaning.

   So, an encoding is an agreement of a precise set of definitions of the textual meaning of each specific sequence of “0s & 1s”. It is often standardized and named (like ASCII or UTF8). This way, we can all agree beforehand on the encoding we use, so that our programs know how to make sense of the data.

   In particular, your code editor is a program and so it needs to know what encoding to use for your source files.

2. Encodings
   • Pick UTF8.
   • UTF8 is the de-facto encoding for many other things (web pages, database tables, text transmissions).
   • All binary data are just “0s & 1s” ⇒ we need an encoding to define what each sequence means.
   • An encoding is an agreement of a precise set of definitions of the textual meaning of each specific sequence of “0s & 1s”.
   • Encodings are standardized and named (like ASCII or UTF8).
3. Fonts

   Just as code editors use UTF8 out-of-the-box, they have good default fonts to display the code. You will find a lot of discussions around code fonts and they dwell on a cornucopia of points. I think only two are fundamental, the rest is cosmetic.

   1. Pick a monospace font.
      Every character of such a font takes the same width. Indentation is regular and pleasant, in fact the whole code is, with every character nicely aligned with one another. Scanning the code is easier, so is editing.
   2. Ensure your font presents no ambiguous display, that is the visual of all characters must be distinct from every other one.
      This sounds like a hassle but if you pick a monospace font meant for coding, you will be fine. Anyway, the common confusions are between:
      • zero 0 and uppercase o: O (letter n°15)
      • one 1 and lowercase el: l (n°12) and uppercase i: I (n°9)

      Other confusions are possible, like two and uppercase zed, but less so as they happen because the characters are similar to one another. For the characters I mentioned above, they can actually be identical. I kid you not.

      Having visually identical characters means every word is an occasion for confusion but two specific situations are worth noting. Several mainstream programming languages have special syntaxes for numbers and one such syntax is 0x… to quickly write a number in hexadecimal. If the zero get displayed as uppercase O, the number can be mistaken for a variable.

      But the worst syntax is like this: 32l. Ending with a lowercase l means you want the number to be stored as a “Long” in memory. If the l is displayed as 1, you will get its size in memory wrong as well as its very value wrong, thinking it's 321 —three hundreds and twenty-one— when it actually is 32.

4. Fonts
   1. Pick a monospace font.
   2. Ensure your font presents no ambiguous display.
   3. Common confusions:
      • zero 0 and uppercase o: O (letter n°15)
      • one 1 and lowercase el: l (n°12) and uppercase i: I (n°9)
   4. Common confusing situations:
      • writing hexadecimal numbers with syntax 0x…
      • writing an explicit long number with syntax 32l
5. Intermezzo: passwords

   With code, the font issue is mitigated by clues like: syntax highlighting and name checks from your code editor, warnings from a build process (like a compiler or a type-checker) and of course failures from your own tests.

   When entering passwords, none of these safeguards exist. As I'm writing this, I got the issue just two months ago. My phone could not connect to a wifi endpoint. Wrong password it said. Of course, knowing about the font issue, I immediately looked for the commonly confused characters and, sure enough, I entered a lowercase “el” instead of an uppercase i.

   When a password you manually entered is wrong, check first whether the font is okay by entering the commonly confused characters. You may solve your problem right away, without launching a grand investigation.

6. Intermezzo: passwords

   When a password you manually entered is wrong, check first whether the font is okay by entering the commonly confused characters.

7. End of line (EOL)

   Short version: ensure your code editor is setup with the line-feed character for end of lines (LF for short). It works fine for almost everything. You will rarely need to change it and there is a good reason not to. As switching your EOL modifies all the lines, any visual diff will report your whole file. To have sane visual diff, do not change the EOL.

   To kill two birds with one stone, setup an auto-formatter. You will never have to think about the EOL stuff. And the code format will be uniform so less changes will be about the format only, improving the info/noise ratio of your diffs.

   I would go so far as to say that this EOL subject is not good knowledge per se. It's just the kind of issues that is quickly fixed, but only if you knew about it. So know that it used to depend on the operating system (see table below) and is now only applicable for text data going through old & platform-specific softwares.

   OS	EOL
   Linux / Unix / all macOS	LF
   Windows	CRLF
   Old Mac (before ~2001)	CR

   And I believe that, if you ever encounter an EOL issue, the most probable situation is not that you picked the wrong one (again, LF now works fine everywhere). My bet is more on this: you got an old project, the files are not LF style and you need to convert them to LF first. Even then, I've read that recent technologies may do just fine without the conversion.

   For instance, I am on Windows 10 and I sometimes code .bat files, which are Windows specific script files, running on a technology that goes back to the 1980s. So I use the CRLF line ending, to err on the safe side. As I'm writing this, I just tested if the LF style is fine. It is, even for something that old and platform-specific.

   

   photo by cottonbro studio

   Finally, you may wonder what are these CR & LF characters? Why not just a simple newline character? Ending lines with CRLF makes sense once you learn that, in the old days, characters were the input of typewriters and they controlled a lot of things, not just the content (for instance, there is a bell “character” to trigger a little alarm).

   CR & LF are such control characters because CR causes the carriage to come back, setting the text to its initial horizontal position, while LF makes the cylinder roll by a notch, effectively moving the text vertically to a fresh new line.

   Given how a typewriter is working, you need both characters to tell the typewriter to move to a) the start of b) the next line. As often with computers, some things are with us because of backward compatibility (and lazy inheritance too). And then enough time has passed and they stop to matter, for a variety of reasons.

8. End of line (EOL)
   • Pick LF.
   • Do not change the EOL.
   • Setup an auto-formatter for your code.
   • Just in case:

     OS	EOL
     Linux / Unix / all macOS	LF
     Windows	CRLF
     Old Mac (before ~2001)	CR

9. “Bonus”: horizontal tabulation

   I think you only need to know four whitespace characters. And since we have an obvious one: the regular space character, right here, between each of these words you are reading, and since the section above dealt with CR and LF, that leaves us with the horizontal tabulation, or tab.

   First, the tab is commonly used for indentation in code files. It's no big deal: any decent code editor handles tabulations well. But should you force a visual of all whitespace characters, your code editor might display some arrows where there was some spaces. This means the blank space is a tab, not the regular space character. For this one, editors usually use a vertically centered light dot.

   Two, the tab is used in tabular data files as the separator between fields. A classic format is CSV, short for comma-separated values. Variants use different separators though ; I encountered for instance the semi-colon, the pipe | and, of course, the tab.

   Three, let's extend reason n°1. Sure, you will see tabs in code files. But should you use it too? First, setup an auto-formatter. It will take care of indentation uniformly, just like with the EOL. Second, tons of discussions exist about whether to indent with spaces or tabs. Nothing stuck with me. I use spaces for the sole reason that they work the same on all code editors, without any configuration.

10. “Bonus”: horizontal tabulation
    • You only need to know four whitespace characters:
      1. the regular space character (used everywhere)
      2. LF (used as end-of-line)
      3. CR (used as end-of-line, rare nowadays)
      4. the tab (used for indentation in code files or as a field separator in tabular data files)
    • Use spaces for indentation: it works the same everywhere, no configuration needed.
    • Setup an auto-formatter.

The point of development is not only to program but to master a given project or at least parts of it. This requires the following interdependent activities (and for which you will need to know some shortcuts):

All interdependent, all parts of mastering a project.

• save changes
  Ctrl + S, do it often. It's crucial to not lose your work.
• undo / redo the last change
  This one is weird: I never see enough emphasis about undoing something. A classic is quitting Vim, a joke at this point but also a telltale about our industry. Know how to undo things, think about how to undo. This applies far beyond your code editor.
• disable code
  Continuation of undoing. There are two ways to stop code to have an effect: deleting it or commenting it.
• use the existing code
  A major point of code editors is to help you with the existing code. That's because the existing code is fundamentally involved in everything we do.
• searching
  Continuation of the previous point. You have to be able to find things in one code file, in your project, and in many projects. This skill is crucial when fixing a bug or understanding an existing feature you need to enrich.
• reading
  Continuation of the previous point. Finding often starts with looking for a given word. It often ends with understanding the code at matching locations. You will need to read code and it's never a waste of time, as it is of great help to write better code.
  Also, use an auto-formatter so that your code is always well-presented by default.
• moving across code
  Continuation of the previous point. Code piles on and there are many ways to organize it, some greatly structured, others less so (but all being a matter of preferences). None dispenses you of moving around in your code files & overall project.

• save changes ⇒ Ctrl + S
• undo / redo the last change
• disable code
• use the existing code
• searching
• reading
• moving across code

This list is for Visual Studio Code and is not meant to be comprehensive. The key bindings are just my habits (and often the default bindings). Do try them: they all have direct effects that are easy to understand and they are useful with any text, not just code.

(1): key bindings differ among editors.
Also note that VS Code already uses Ctrl+D to collect one by one matches of your search. Then you can do “replace ” on the collected matches. Some people seem to like this shortcut a lot. Personally, I have no use for it: I either directly replace things one by one, all at once without looking, or work in a dedicated tab in my second editor.

(2): key bindings differ among editors, so does the behavior.
Ideally, it would toggle a single line comment if only one line is selected, and a block comment if several lines are selected.

(3): key bindings differ among editors.
Also useful to track my advancement as I only leave open the definitions I'm working on.

(4): key bindings differ among editors.
Useful for classes (folds the methods in it) and for big functions.

(5): key bindings differ among editors.
Useful to fold the cases of a switch block in a function.