how blind people program 的问题已经得到了一遍又一遍的回答，但我找不到任何关于失明和使用屏幕阅读器或盲文显示器如何影响你的编码风格的信息。
你能将盲人创建的代码与其他代码区分开来吗？
盲人是否会导致您对问题有不同的看法并寻找其他解决方案？
【问题讨论】：
标签： workflow accessibility development-environment
我是一个盲人开发者。我将尝试根据我所做的以及我在其他盲人开发人员的代码中看到的内容来回答您的问题。 但是，请记住，我的回答绝对不是参考。可能与有视力的普通开发人员一样多的不同用法、习惯和偏好。
在公司和/或开源项目中工作时，无论如何，我们都必须按照给定公司和/或项目的规则定义我们的代码格式。毫无疑问，这是必需的。 在这种情况下，我和我认识的大多数盲人程序员首先编写未格式化的代码、编译、测试等，并且仅在提交时才格式化。 IDE 中的自动格式化工具非常珍贵，否则通常会很痛苦。如果不使用 IDE，命令行工具也很常见，例如用于 Java 和 C/C++ 的样式。
如果公司和/或项目不需要给定格式，我们中的许多人：
} // end for。当需要这样做时，它可能是一个很好的指标，告诉我们应该更好地组织代码/更好地拆分成不同的功能。//constructor，可以通过 Ctrl+F 立即找到，但也可以更微妙。例如，我个人的一个技巧是在定义或声明函数时在名称和打开的父级之间放置一个空格，但在调用函数时不要。所以我可以快速找到定义（通过搜索“name(”)，或调用它的地方（通过搜索“name(”））。/********** 的长行
import java.util.* 而不是一一导入 50 个类。【讨论】：
好吧，我部分回答了这个问题here。基本上，你很少能看出一段代码是由盲人编写的，除非他/她以非常粗鲁的方式违反规则（例如，像我一样在 Python 中使用制表符和驼峰式而不是空格和蛇形大小写）。
但即使是这些东西也可能只在个别宠物项目或快速而肮脏的脚本中看到。大多数盲人承认他们生活在一个有视力的世界中，如果您希望合并您的拉取请求或由工作上级审查您的代码，您必须遵守项目，不管你喜不喜欢，不管你是不是盲人。在这种情况下，Go 的人们做出了一个明智的决定，即包含一个格式化工具，每个 Go 开发人员在提交他/她的代码之前都必须运行该工具。 “没有人喜欢 Gofmt 风格”，Rob Pike 说，他错了：我非常喜欢它的风格：camelCase 和标签，多么美味的东西！但即使您不喜欢它，也必须运行该工具，因为这是语言规则。
对于你问题的最后一部分：是的，有时失明会让我选择一种解决方案，即一种语言。因为我讨厌snake_case，所以我无法考虑在Rust 中进行严肃的开发，例如，因为（再次）编写这样的代码是一种语言规则。我确实编写了 Python 代码，但它......哦，好吧......其他的东西，因为 Python 在解决日常问题方面是如此快速和灵活，所以我决定在这里处理它的（烦人的）多个下划线和没有块结尾标记。顺便说一句，盲人编码器的另一个可能标志是这样的 cmets：} // end if（在 Javascript 或 C 中），或 #end if 在 Python 中作为一整行。我不否认有视力的人可以使用这些，但如果你看到每一个 if 和 for 以及 while 结尾都这样评论，那么代码很有可能是由盲人编写的。我个人不这样做，但我认识非常喜欢它的人。
【讨论】：
我知道这个问题已经很老了，但答案可能仍然相关： 我是盲人开发人员，我总是打算遵循公司的编码风格或语言开发人员给出的某些标准。
【讨论】：