7 Great reasons why I love Visual Studio code editor, and why it might be the best for screen reader users

Hello folks, another web development related post from me. Prepare yourselves to spend a bit of time on this post, because it’s a bit longer, reason being that it is very detailed and I tried to explain all the reasons I think Visual Studio code is the best code editor, For the blind and visually impaired individuals, and not only that, I will explain you in detail why that is the case.

In this post I will give you 7 distinct reasons why I think VS code is best and why you should use it yourself If you are a developer.

Okay boys and girls, before giving the 7 awesome reasons I will start with a short back story which should provide some context hopefully, why did I choose Visual studio code as my primary choice.

How it all began

I started to write web applications at the young age. By then, I didn’t know a value of integrated development environment (IDE) and I just used regular Notepad for such tasks as coding. It was fine for coding such a small applications as simple authentication system, as well as few simple HTML, + JS + CSS based forms in front-end, and PHP + MySQL at back-end. Later I had been tempted to make text-based browser game with one friend of mine, that’s how I switched to Slightly upgraded version of Notepad known as Notepad++. I am assuming that most of the readers of this article knows what it does and how it works. It has a bit more functionality than a standard notepad does. For example, it recognizes the need of code indentation and gives some colorful syntax which was helpful when we were coding together with only one computer. Also, it helped to deal with proper text encoding.

Later on, the time came when I had to learn C++. to learn that language, I decided to use a well-known IDE Visual Studio, it’s not the same as Visual Studio code though.). According to visualstudio.microsoft.com, Visual Studio is “Full-featured IDE to code, debug, test, and deploy to any platform”. It sounds strange right? Visual Studio code and Visual Studio are different applications even though they are used for similar reasons, which are coding of course. Anyway, the primary reason for using Visual Studio was to create Windows console applications, also at the time I felt that this IDE was very accessible way to code, it actually was, and still is today. However, in my experience that I had it been quite slow, maybe it is way faster now, I don’t know, it probably is, plenty time went by since the last time I tried it. If you’re planning to write C Sharp / .net applications, probably it’s your best bet,

hence, I am a web developer, I needed something different. And thus, I landed on Eclipse IDE for PHP. It has plenty features to deal with your source code like code completion, auto indentation, code navigation and even debugging at certain level. IDE loading time is really slow and there are some tweaks that you need to watch out for, but since I’m talking about Visual Studio Code today, I’m not going to go to any more details, however you can check Eclipse IDE for yourself and try it on your own if you want: eclipse.org/downloads/packages/release/helios/r/eclipse-php-developers

I even tried and experimented with very well-known Ide: PHP Storm. In my humble opinion, it is really good for sighted developers and is fully featured IDE with terminal, code completion, easy source code navigation, refactoring, code folding, auto indentation, Laravel support, support of various templates, following coding standards, proper documentation, debugging tools, errors and / or warnings in your code, Docker integration, GIT support and many other good features. However, it’s only partially accessible. For instance, you can not debug with it or use integrated terminal, some tools are laggy, so Therefore I didin’t stick with PHPStorm for a long time. however, it’s worth to remember that they’re supporting some level of accessibility so maybe now it’s a bit better than it was the last time I played with it.

1 of the major web development requirements was for me as it is for any web developer, I had to be very quick in terms of coding if I wanted to get a good job. That finally led me to my favorite code editor as of today: Visual Studio Code. or in short – VSCode. If you aren’t experienced developer, you might think oh, well, you might stick with Notepad++ since it’s accessible, why not? However, when we are talking about code quality and maintenance, then we can not work with a lot of code such a way like this. Why you might ask? Answer consists of many things in common, but in this article, I want to reveal what VSCode can do and how you can be faster as a developer by leveraging this technology.

1st of all, lets define what actually VS Code is. VS Code is a lightweight open-source editor written and maintained by Microsoft. It has tuns of extensions that you can install to satisfy your needs. It doesn’t matter if you’re writing code in PHP, Node.js, C++ or in other language, you can always find suitable extensions for your particular case. In case of extensions, you can think of VS Code as an editor that you can turn into an IDE. Furthermore, VS Code works on Windows, MAC and Linux, so you’re free to choose the best platform for you. And furthermore, Microsoft really pays attention to accessibility of VS Code, so you can use JAWS, NVDA, VoiceOver or Orca as your screen reader.

So now, lets dive into those seven promised important reasons, why I think Visual Studio Code is the best IDE for the blind and visually impaired:

1: Auto indentation

Good code indentation is really common thing amongst sighted developers. Main reason for it is just code readability. It works simply because when the inner blocks are indented, sighted developer can Visually differentiate when and where exactly block of code ends, so it is possible to quickly jump through peace’s of a code. It seams that code indentation can not give anything to the blind people, but that’s not true. In my daily workflow I turn on NVDA’s Line indent reporting feature on my VSCode development profile. It reports how many tabs or spaces are before the actual code at the beginning of the line and then reads the code. It doesn’t repeat the same indentation level at every line when you move along, it just informs you about indentation changes. That way you can move through the code much faster and should not care about the number of right braces you pass to find an exact ending of a desired block to edit things. it is just enough to remember the indentation level

I see only one problem here – how to carefully indent things and do not make mess when copying and pasting, cutting things and editing. Answer is simple – we can use VSCode’s auto indent feature which indents the code when you create new block or you can Re-indent your code when you’re happy about the results (just to make it clean and readable). It understands many different scripting and programming languages, you just need to install a proper extension for language of your choice and you’re good to go. You even can jump to the next closing bracket to find where your current indentation level ends.

2: Code folding

Code folding is a feature that allows you to hide certain code indentation levels, code block comments or documentation blocks when you don’t need them. For example, if you fold your code comments, when you navigate through the source code with your keyboard, comment blocks are just skipped and you move along. On Visual Studio Code folding works by utilizing a feature of code indentation. You can fold / hide or unfold / unhide certain levels of code indentation. Let’s imagine that we have a class named User which holds only one property / field called name and two methods such as setter and getter for that name. Global code, which is outside of a class should not be indented, but might have some documentation in terms of author, package and explanation of what this class can do. Property called name is within the class, so it should have first level of indentation, so indented with one tab or four spaces. Contents of methods as getter and setter should be indented with second level, such as eight spaces or two tabs respectively. Keeping in mind that class example we can fold / unfold our code in terms of levels. If we fold the second level of indentation, we will see only global code, class with its property name and only definition of the setters and getters, without an actual code in those function blocks so we can quickly jump through the class methods there.

3: Git support

Git is really an important tool nowadays, especially when you’re working at the big tech company. VS Code has Git integrated by default, so you can stage your modified project files directly in VS Code instead of going to the terminal and typing git add and giving a path to the file. Un-staging files is also easy, instead of typing git reset (followed by file path), you can just pick a file you want to un-stage (in your source code control treview). Instead of typing git commit -m “followed by commit message”, there’s enough to open-source control, type commit message and press CTRL + ENTER and your staged files get automatically committed. Pushing is also very simple – just pick push option in the source control menu and your branch will be pushed to the remote server automatically. There are actually tuns of actions that you can do including, but not limited to pulling code updates from a remote branch, creating branches, preview commits history, history of a file, even of a line with detailed information of an authors that committed the particular line, searching in commits by author, commit message and other criteria. Also, if you need to switch between your branches frequently, you can stash and unstash your branches with ease. Just hit CTRL + SHIFT + P and type git stash, pick one of a suggested menu items and enter a stash message, or choose a stash to unstash on the current branch. Stashing is really helpful, because it just saves your current work as a snapshot and lets you to quickly resume your work, even on a different branch if you wish.

Despite of fact that many developers hate merging conflicts and blind people might hate those conflicts even more, VS Code gives as an opportunity to work as sighted people do for so long already. Let’s say you want to merge newest pulled updates from your master branch into your feature branch. If you’re working with many developers together, there is a big chance that someone else touched the same code as you did so Git notifies you that there’s a merge conflict if you would issue a command as git merge master (on your feature branch) within terminal. In VS Code you just press CTRL + SHIFT + P and that would open command pallet where you just start typing git mer… and you would get list of similar commands so you can pick the right one. Then if you would pick git merge from the list, another list would give you all of your branches so you can choose master branch and that way you merge it into your feature branch. If merge conflict pups up, your source control gives you merge conflict group of files where you can see an actual file that have a problem when Git tries to merge them. Let’s say you open file with the conflicts, so there are commands that let you to move to the next / previous conflict within the file. When you find a conflict, you can choose if you want current changes (in other words – your changes) or incoming changes (in other words – changes that are made in the master branch, likely by the other developers), or maybe you want to keep both changes including yours and the incoming ones. You can freely edit that source when you merging as well as letting incoming or current changes to dominate across file if you see no need of going through each conflict manually. Diff tool gives you a way to see an exact change within files by giving you a version of the same file from your feature branch and the master branch with a detailed explanation which lines were modified / removed and so on.

I know that all the actions I mentioned here can be done by using terminal, but is it terminal the best and the simplest way to do these tasks? That’s for you to decide.

4: Great debugging experience

In short terms, debugging is the process of detecting and removing an existing or potential error and / or mistakes of a program during it’s run-time. It isn’t easy to detect such errors, because they usually appear at run time and when some conditions are met or otherwise you might even do not notice them for quite long. I know many PHP developers who don’t see the reason to use a debugger, because they think that is enough to print objects / variables to the screen and follow the call stack to detect the issue. I was one of them quite a long time, but not anymore! Yes, sometimes it’s enough just to print stuff out and see what’s wrong, but there are moments when you really get stuck and even if you think that code runs as you think it does, well, let’s say, it’s just what you think, but not necessary exactly what’s happening.

VS Code has plenty of extensions that you can install to debug your software before deploying it to production servers. Since I work mostly with PHP in my job, I’m talking about this language particularly, but process is nearly the same with C++, Python, Node.js and other languages so it should not confuse you. For me it’s just enough to install Xdebug extension to my PHP on the server side and PHP Debug extension in VS Code and I can proceed.

Debugger and VS Code can work together to give you an experience of code execution. Debugger works by letting you to put a breakpoint within your source code (just where you want to pause your program from being executed). IDE sends an information about the breakpoints to the Xdebug on the server in this particular case), and Debug extension instructs PHP’s interpreter to do the pause at the same line where the breakpoint is. You can add as many breakpoints as needed and add or remove them even during a run-time, but debugger should hold program from being executed at that particular moment. All in all, you can pause or resume an execution of a program and execute your program line by line, function by function or when some specific condition is met or when some exception is thrown.

When your program hits the breakpoint, it pauses and since you can move line by line exactly the way as your source code is being executed, you can notice things faster without trying to imagine what your code does at that particular moment, you can actually see what’s happening without turning on your imagination and that really helps. Debugger displays information about local, global and class variables to you all the time in a treview structure (you can see your objects or arrays being layed out in real time) and as magical it might sound, you can use VS Code console to execute your code that you type in console, for instance to change a value of variable and then resume execution to see how will code respond to that particular value. You can also see the call stack all the time so you know which function called another one and which file has the body / source of that function so you can actually find it and read / debug it. When debugger hits the breakpoint, IDE opens currently executed file for you and as you go along with source code execution, it keeps opening currently executed file as you go so you can even find files of some libraries that you didn’t know about and how to quickly find them.

5: Outstanding source code navigation

Despite of things I mentioned here, we need a good and especially a quick way to navigate through the source code. VSCode allows us to search for files within project (by file name – complete or partial), for a code / contents within files of a whole project, and for a contents / code within currently opened file. Furthermore, you can go to a symbol (which is a method, variable, interface, trait, class and etc.). With that said, you can open some file and see the list of methods within it and quickly jump to the selected method. That really makes your navigation faster. It is quite simple to find definition and declaration of the method that interests you. You just need to focus cursor on the method that’s being called and press F12 to get you there. If you press SHIFT + F12 you will get list of files with exact line numbers and their code where the selected method is being called. SO, you can easily jump through methods and variables with their definition and to check how can they be accessed and so forth. As a matter of fact, you can even find an implementation of an interface (which classes have that particular interface implemented), the same logic works with abstract classes and their methods. Even refactoring works the same way. You just need to select the name of a symbol you need to refactor, press F2 and it will be automatically renamed across files and that’s only one example.

6:  Magic of IntelliSense

I will not explain exactly what IntelliSense does, but basically it analyzes your source code when you write or move along and gives you suggestions and you can pick one which satisfies you. It even gives you hints about function parameters and really helps when you’re writing that long named variable of yours and can not remember exactly how it’s named. More about VSCode’s IntelliSense you can read here: https://code.visualstudio.com/docs/editor/intellisense

7:  Smooth WSL and remote development integration

I wrote an article about WSL 2 and how that Linux environment helps developers to stay on Windows, and use Linux environment to do so.  WSL2 also allows to develop applications for Linux, for full description and more details you can use the link below to access the article:

techvb.net/2021/04/27/wsl-for-dev/

I’ll try to explain how VSCode helps here. The beautiful thing about WSL and VS code is that it has very good integration that works seamlessly together.

Actually, you are only required to do 2 things

1 set up WSL2

2 install WSL extension to VS code.

Then VSCode will work not only in your Windows environment, but in your Linux environment too. All of this is possible because of a server that VSCode installs into your Linux distro behind the scenes. Your Windows and Linux VSCode extensions are separated so those that you’re installing to your WSL will not be mixed with those on your host machine. Basically, everything will be local-based. Your code will live in your Linux distro, VSCode server will be on your distro too, so VSCode on Windows just stays as a client with UI on top and quickly sends commands to your VSCode on WSL to be executed. It will not slow you down, because it’s the same computer and smooth integration, so the effect will be the same as you would write code on your Windows, just better.

 Why better? You’ll get Linux based paths on your project like /var/www/my-project instead of c:\wamp\www\my-project and since all major companies work on Linux environment, your code will be the same as it is on production environment – just consistency which let’s you to code as your co-workers do.

Sometimes you need to work with a source code that’s not in your machine so how to deal with it? Answer is simple enough too. Just install VSCode’s Remote extension and you will be able to connect to the server via Secure Shell (SSH) protocol. I have to say it feels like is almost like you would’ve opened a directory by using WinSCP or FileZilla FTP client with a difference of an IDE!

I will not go any further on explaining useful features of VSCode, because there are tuns of others like syntax highlighting, go to next error / warning (where you can check your syntax errors), Docker integration, tuns of keyboard shortcuts, Keymaps, plenty of extensions that help in different circumstances, various helpful settings for the visually impaired and just others in general.

Finishing thoughts

The features and capabilities of visual studio code, would require the entire book and then some, to explain its vast number of features and capabilities.

Assuming I would write the book, that will take about 6 months to doo it, and by then 25% increase of more new features will be released that I haven’t covered, because Microsoft is doing a great job in updating the editor and fixing the bugs.

I want to say one more time though, I do respect the Microsoft attempts in making this code absolutely accessible, furthermore it constantly adds and fixes accessibility related things in each and every update, which is outstanding.

I hope the information above made sense to you, and now you are slightly more knowledgeable about vscode features and capabilities.

I indeed do recommend you try the visual studio code for yourself, 1 because it’s absolutely free and 2 as I explained above it works great with screenreaders.

It was a long article I know, but complicated topics like these usually do require some explanation, and more complicated things usually do require more complicated explanations, and as a result of that we write longer articles like this one.

As always, we say at TechVB, feedback and ideas are appreciated, and you can do that by using the contact form.