How does being blind affect your coding style?

Question

The question of how blind people program has been answered over and over already, but I couldn't find anything on how being blind and using a screen reader or braille display affects your coding style.

Can you tell code created by blind people apart from other code?

Does being blind cause you to think differently about a problem and look for other solutions?

Answer 1

I'm a blind developer. I will try to answer to your question according to what I do and what I already saw in codes coming form other blind developers. However, remember that my answer absolutely isn't a reference at all. There are probably as many different usages, habits, preferences as sighted common developers have.

When working in a company and/or for an open source project, we have anyway to format our code as defined by the rules of the given company and/or project. There is no question, it's required. IN this case me and most of the blind programmers I know of first write unformatted code, compile, test, etc. and only format it when it's time to commit. Auto-formatting tools as there are in IDE are extremely precious, otherwise it would often be a real pain. If not using an IDE, command-line tools are also common, e.g. astyle for Java and C/C++.

If a given format isn't required by a company and/or project, many of us:

• don't indent code, as it usually is more pain to navigate and edit within it, especially if we want to take care of not breaking it. In contrary to sighted people, indentation generally don't help us to quickly identify blocks. Even with a braille display if we have one, we can only see one line at a time.
• use other tricks to identify where blocks end, if necessary in case of doubt / when nesting is deep. Most often, this takes the form of a comment following the closing brackets, e.g. } // end for. When the need arrise to do this, it can be a good indicator to tell us that we should better organize the code / better split into different functions.
• use a lot of small tricks to be able to jump quickly to a part of code of interest. This can be simple comments like //constructor, which can be immediately be found with Ctrl+F, but it can also be more subtle. For example, one of my personal tricks is to put a space between the name and the open parent when defining or declaring a function, but don't when calling the function. So I can quickly go to the definition (by searching for "name ("), or the places where it is called (by searching for "name(").
• hate ASCII art because it's totally useless, ex: a long line of /**********
• often use shortcuts to avoid long code that give no real information, e.g. import java.util.* instead of importing 50 classes one by one.
• often prefer using simple text editors rather than complex IDE, or only use them for specific functions such as auto-formatting because it's absolutely needed. Two reasons for this: many IDE are unaccessible, only partially accessible, or are mostly accessible but it's not necessary easy or comfortable to use a given feature; or because responsiveness with speech and braille displays is quite poor, i.e. when pressing up/down arrow to read the next/previous line of code, there is a too long delay before it starts speaking (it becomes quickly very annoying, if you multiply 100ms a thousend times).