盲目如何影响您的编码风格？

Question

how blind people program的问题已经反复回答，但是我找不到任何关于如何失明的信息，使用屏幕阅读器或盲文显示会影响你的编码风格。

除了其他代码之外，您能告诉盲人创建的代码吗？

盲目会导致您对某个问题有不同的看法并寻找其他解决方案吗？

Answer 1

好吧，我部分回答了这个问题here。基本上，你很少能说出一段代码是由一个盲人写的，除非他/她以一种粗鲁的方式打破规则（例如，在我的Python中使用制表符和camelCase而不是空格和snake_case）。登记/> 但即使是那些东西也只能在个别宠物项目或快速而肮脏的脚本中看到。大多数盲人都承认他们生活在一个有视力的世界中，如果你想要你的拉动请求合并或者你的代码要由上司在工作中审查，你必须遵守代码造型。项目，无论你喜不喜欢，你是否是盲人。在这种情况下，Go的人明智地决定在提交他/她的代码之前包含每个Go开发人员必须运行的格式化实用程序。 “没有人喜欢Gofmt风格”，Rob Pike说，他错了：我非常喜欢它的风格：camelCase和tabs，多么美味！但即使你不喜欢它，你也必须运行该工具，因为这是语言规则 在你问题的最后一部分：是的，盲目有时会让我选择一种解决方案，即一种语言。因为我讨厌snake_case，所以我无法考虑Rust中的严重开发，例如，因为（再次）编写这样的代码是一种语言规则。我确实编写了Python代码，但是......好吧......其他的东西因为Python在解决日常问题方面非常快速和灵活，我决定在这里处理它的（恼人的）多个下划线并且没有块结束标记。 BTW，盲人编码器的另一个可能的标志是这样的评论：} // end if（在Javascript或C之类的东西），或者#end if作为Python中的整行。我不否认有视力的人可以使用这些，但是如果你看到每个if和for和while结尾都这样评论，那么代码很可能是由一个盲人写的。我个人不这样做，但我知道非常喜欢的人。

Answer 2

我是盲人开发者。我将根据我的工作以及我在其他盲人开发人员编写的代码中看到的内容，尝试回答您的问题。 但是，请记住，我的答案绝对不是一个参考。可能有很多不同的用法，习惯，偏好和看见的普通开发者一样。

当在公司和/或开源项目中工作时，我们无论如何都要格式化由给定公司和/或项目的规则定义的代码。毫无疑问，这是必需的。 在这种情况下，我和我所知道的大多数盲人程序员首先编写无格式代码，编译，测试等，并且只有在提交时才进行格式化。 IDE中的自动格式化工具非常珍贵，否则通常会是一种真正的痛苦。如果不使用IDE，命令行工具也很常见，例如适用于Java和C / C ++的astyle。

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

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

Answer 3

我知道这个问题很老了，但答案可能仍然相关： 我是盲人开发者，我总是想遵循公司的编码风格或语言开发者给出的一些标准。

1. 我总是在编写代码时立即缩进，并且屏幕阅读器会报告缩进级别。老实说，我不再有阅读无格式代码的习惯，但我知道有盲人会这样做；
2. 定期进行文档屏蔽；
3. 当我需要浏览大块代码时，折叠/展开代码的某些部分；
4. 常规的蛇形/驼色习惯（取决于语言）；
5. 有时会编写更长的代码行，然后使用 IDE 来修复格式，因为对于我而言，较长的代码并不总是更复杂；
6. 尝试强制自己将一行的长度限制为不超过 80 个字符，但由于缺乏良好的工具，要确保做到这一点有点痛苦；
7. 有时会添加一些有用的注释来帮助我调试代码（我的意思是注释中的一些计算/公式对其他人来说并不重要，但这取决于）。 就我个人而言，我发现最大的挑战是在文档块（注释）中编写代码，例如在 Doctrine 或 APIPlatform 中，因为屏幕阅读器读取行中第一个非空格/非制表符的缩进，这是星号 (*)在文档块的情况下。