失明如何影响您的编码风格？

Question

盲人如何编程的问题已经被一遍又一遍地回答了，但我找不到任何关于盲人和使用屏幕阅读器或盲文显示器如何影响你的编码风格的信息。

你能区分盲人创建的代码和其他代码吗？

失明是否会导致您以不同的方式思考问题并寻找其他解决方案？

Answer 1

我是盲人开发者。我将尝试根据我所做的以及我在其他盲人开发人员的代码中已经看到的内容来回答您的问题。但是，请记住，我的回答绝对不是参考。可能有与普通开发人员一样多的不同用法、习惯、偏好。

在公司和/或开源项目中工作时，我们无论如何都必须按照给定公司和/或项目的规则定义我们的代码格式。毫无疑问，这是必需的。在这种情况下，我和我认识的大多数盲人程序员首先编写未格式化的代码、编译、测试等，并且仅在提交时对其进行格式化。IDE 中的自动格式化工具非常宝贵，否则通常会很痛苦。如果不使用 IDE，命令行工具也很常见，例如用于 Java 和 C/C++ 的 astyle。

如果公司和/或项目不需要给定的格式，我们中的许多人：

• 不要缩进代码，因为在其中导航和编辑通常会更痛苦，特别是如果我们想注意不要破坏它。与视力正常的人相反，缩进通常无助于我们快速识别块。即使有盲文显示器，如果我们有盲文显示器，我们一次也只能看到一行。
• 如果有疑问/嵌套很深时，如有必要，使用其他技巧来确定块的结束位置。大多数情况下，这采用右括号后面的注释形式，例如} // end for。当需要这样做时，它可以是一个很好的指标，告诉我们应该更好地组织代码/更好地拆分为不同的功能。
• 使用很多小技巧可以快速跳转到感兴趣的代码部分。这可以是简单的注释，如//constructor，可以立即使用 Ctrl+F 找到，但也可以更微妙。例如，我个人的一个技巧是在定义或声明函数时在名称和打开的父级之间放置一个空格，但在调用函数时不要。所以我可以快速转到定义（通过搜索“名称（”），或调用它的地方（通过搜索“名称（”））。
• 讨厌 ASCII 艺术，因为它完全没用，例如：一长串 /**********
• 经常使用快捷方式来避免没有实际信息的长代码，例如，import java.util.*而不是一个一个地导入 50 个类。
• 通常更喜欢使用简单的文本编辑器而不是复杂的 IDE，或者只将它们用于特定功能，例如自动格式化，因为它是绝对需要的。这有两个原因：许多 IDE 无法访问、仅部分可访问或大部分可访问但使用给定功能不一定容易或舒适；或者因为语音和盲文显示的响应能力很差，即当按向上/向下箭头阅读下一行/上一行代码时，在开始说话之前延迟太长（如果乘以 100 毫秒，它会很快变得非常烦人）千百年）。

Answer 2

好吧，我在这里部分回答了这个问题。基本上，您很少能分辨出一段代码是由盲人编写的，除非他/她以非常粗鲁的方式违反规则（例如，像我一样在 Python 中使用制表符和驼峰命名而不是空格和蛇形大小写）。
但即使是这些东西也只能在个别的宠物项目或快速而肮脏的脚本中看到。大多数盲人承认他们生活在一个有视力的世界，如果你希望你的 pull request 被合并或者你的代码被工作上的上级审查，你必须遵守项目的代码样式，无论你喜欢它还是喜欢它。不会，不管你是不是瞎子。在这种情况下，围棋的人们做出了一个明智的决定，包括每个 Go 开发人员在提交他/她的代码之前必须运行的格式化实用程序。“没有人喜欢 Gofmt 风格”，Rob Pike 说，他错了：我非常喜欢它的风格：camelCase 和 tabs，多么美味的东西！但即使您不喜欢它，您也必须运行该工具，因为这样做是语言规则。
关于你问题的最后一部分：是的，失明有时会让我选择一种解决方案，即一种语言。例如，由于我讨厌 snake_case，我无法考虑在 Rust 中进行认真的开发，因为（再次）编写这样的代码是一种语言规则。我确实编写了 Python 代码，但它......哦......还有其他事情，因为 Python 在解决日常问题时是如此快速和灵活，所以我决定在这里处理它的（烦人的）多个下划线和没有块结尾标记。顺便说一句，盲人编码器的另一个可能的迹象是这样的评论：（} // end if在 Javascript 或 C 之类的东西中），或者#end if作为 Python 中的整行。我不否认有视力的人可以使用这些，但是如果你看到每一个 if 和 for 以及 while 结尾都这样评论，很有可能代码是由盲人编写的。我个人不这样做，但我知道人们非常喜欢它。