How does being blind affect your coding style? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 14 days ago.

Improve this 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).

Answer 2

Well, I answered this question partially here. Basically, you rarely can tell that a piece of code is written by a blind person, unless he/she breaks rules in quite a rude fashion (for example, uses tabs and camelCase instead of spaces and snake_case in Python, like me).
but even those things might be seen only in individual pet projects or quick and dirty scripts. Most of the blind people acknowledge they live in a sighted world, and if you want your pull request to be merged or your code to be reviewed by a superior at work, you must obey the code styling of the project, whether you like it or not, whether you're blind or not. In this situation people at Go made a wise decision to include a formatting utility that every Go developer must run before committing his/her code. "Nobody likes the Gofmt style", says Rob Pike, and he's wrong: I like its style very much: camelCase and tabs, what a delicious thing! But even you don't like it, you must run the tool because it is the language rule to do so.
And to the last part of your question: yes, being blind sometimes makes me to choose a solution, namely a language. As I hate snake_case, I can't think about serious development in Rust, for example, because (again) it's a language rule to write code like this. I do write Python code, but it's... oh well... kind of other thing because Python is so quick and flexible in resolving everyday problems that here I decided to cope with its (annoying) multiple underscores and the absence of block ending markers. BTW, another possible sign of a blind coder is comments like this: } // end if (in something like Javascript or C), or #end if as a whole line in Python. I don't deny sighted people can use those, but if you see every if and for and while ending commented like this, a great chance is that the code was written by a blind person. I personally don't do this, but I know people that like it very much.

Answer 3

I know this question is quite old, but the answer might be relevant still: I am blind developer and I always intent to follow a coding style of a company or some standard given by developers of a language.

1. I always indent my code instantly when I write it and screen reader reports the indentation level. Honestly I do not longer have a habit to read unformatted code, but I know blind people who do;
2. Do the regular docblocking;
3. Fold/unfold some parts of a code when I need to navigate through large chunks of it;
4. Regular snakecase / camelcase habit (depends on a language);
5. Sometimes write longer lines of code and then use IDE to fix the formatting, because it is not always that longer code tends to be more complex for me to read;
6. Try to enforce myself to restrict the length of a line to be no greater than 80 characters, but it's a bit of a pain to ensure that to happens due to a lack of a good tooling;
7. Sometimes add some useful comments to help me to debug code (I mean some calculations / formulas in a comments that are not necessary important to others, but it depends). Personally I found the biggest challenge is to write a code in docblocks (annotations) like in Doctrine or APIPlatform for example, because screen reader reads an indentation to the first non-space / non-tab character in the line which is asterisk (*) in a case of a docblocks.