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 1 year 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?
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).
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.
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.
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;
Do the regular docblocking;
Fold/unfold some parts of a code when I need to navigate through large chunks of it;
Regular snakecase / camelcase habit (depends on a language);
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;
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;
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.
when I try to write an Arabic language words in xcode editor it does not display correctly, it's displayed as messed up words and reversed (the output in iPhone is OK), so it becomes harder for me to review the strings I entered in the editor, is there anyway to overcome this issue ?
I think those are bugs in Xcode (you can try changing the font, but I don't think the direction can be changed).
However, it is generally preferable to write your strings in English and then use internationalization (i18n) techniques to convert and display them in Arabic at runtime. A quick google revealed this blogpost. This solves two issues:
You can support any number of languages.
You can store your Arabic text in a separate file and edit it with an external editor, making it easier to work with.
I am writing a Java app using Eclipse. This app read a set of Hebrew strings (that are right-to-left). Assuming I put these strings is a separate file, how do I tell the Eclipse editor that they are right-to-left text.
I tried eclipse -dir rtl but that puts all of Eclipse in RTL mode which is not the behavior I looking for.
One alternative is to carefully use StringBuilder.reverse() to manipulate the strings as needed after they are read in.
http://download.oracle.com/javase/1.5.0/docs/api/java/lang/StringBuilder.html#reverse%28%29
You could also write some simple string manipulation methods as helpers to handle whatever special needs you have.
This page, found in a quick google search, seems to have some interesting info on how Java handles and renders Hebrew: http://mindprod.com/jgloss/hebrew.html
When we click the check box "Install files for complex script and right to left languages (including Thai)" in Regional and Language settings what exactly happens?
Changes to registry keys?
I noticed that it installs some .fon files and keyboard dlls.
Is this totally necessary if one just wish to read complex script on Windows XP? My test inside VirtualBox as Windows 7 as the host OS seems to indicate that for reading Complex Script need not be enabled. Yet that's not what all the literature on the subject says. What's going on?
Update:
http://hi.wikipedia.org should not be readable if Complex Script is not enabled
http://hi.wikipedia.org/wiki/विकिपीडिया:Devanagari_Help
Problem is that it is readable.
Font files. Rendering libraries ('Uniscript'). Input methods. Certainment beaucoup de cle-registry. (Certainly lots-o-registry-keys.)
Note that IE will tend to get things right even when other things don't, since it builds in a good deal of fancy-pants rendering. Try, oh, Outlook, or some simple sample Win32 program.
I'm not sure if it's my system, although I haven't done anything unusual with it, but I've started noticing incorrectly rendered characters popping up in web pages, text-files, like this:
http://www.kbssource.com/strange-characters.gif
I have a hunch it's a related to the fairly recent trend to use unicode for everything, which is a good thing I think, combined with fonts that don't support all possible characters.
So, does anyone know what's causing these blips (am I right?), and how do I stop this showing up in my own content?
It appears that for this particular author, the text was edited in some editor that assumed it wasn't UTF8, and then re-wrote it out in UTF8. I'm basing this off the fact that if I tell my browser to interpret the page as different common encodings, none make it display correctly. This tells me that some conversion was done at some point improperly.
The only problem with UTF8 is that there isn't a standardized way to recognize that a file is UTF8, and until all editors are standardizing on UTF8, there will still be conversion errors. For other unicode variants, a Byte Order Mark (BOM) is fairly standard to help identify a file, but BOMs in UTF8 files are pretty rare.
To keep it from showing up in your content, make sure you're always using unicode-aware editors, and make sure that you always open your files with the proper encodings. It's a pain, unfortunately, and errors will occasionally crop up. The key is just catching them early so that you can undo it or make a few edits.
I'm fairly positive it's nothing you can do. I've seen this on the front page of digg alot recently. It more than likely has to do with a character being encoded improperly. Not necessarily a factor of the font, just a mistake made somewhere in translation.
It looked for a while like the underscore and angle bracket problem had gone away, but it seems it might not be fixed.
here's a small sample, which should look like this:
#include
____
#include <stdio.h>
____
#include
Update: it looks like it's fixed in display mode, and only broken in edit mode