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

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

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

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

最佳答案

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

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

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

不缩进代码，因为在其中导航和编辑通常更痛苦，特别是如果我们想注意不要破坏它。与视力正常的人相反，缩进通常无助于我们快速识别块。即使有盲文显示器，如果我们有盲文显示器，我们一次也只能看到一行。

使用其他技巧来确定块在哪里结束，如果有疑问/嵌套很深时有必要。大多数情况下，这采用右括号后面的注释形式，例如} // end for 。当需要这样做时，它可以是一个很好的指标，告诉我们应该更好地组织代码/更好地拆分为不同的功能。

使用了很多小技巧，可以快速跳转到感兴趣的代码部分。这可以是像 //constructor 这样的简单注释，可以立即使用 Ctrl+F 找到，但也可以更微妙。例如，我个人的一个技巧是在定义或声明函数时在名称和打开的父级之间放置一个空格，但在调用函数时不要。所以我可以快速转到定义(通过搜索“名称(”)，或调用它的地方(通过搜索“名称(”))。

讨厌 ASCII 艺术，因为它完全没用，例如:一长串 /**********

经常使用快捷方式来避免不提供真实信息的长代码，例如import java.util.* 而不是一一导入 50 个类。

通常更喜欢使用简单的文本编辑器而不是复杂的 IDE，或者只将它们用于特定功能，例如自动格式化，因为它是绝对需要的。这有两个原因:许多 IDE 无法访问、仅部分可访问或大部分可访问但使用给定功能不一定容易或舒适；或者因为语音和盲文显示的响应能力很差，即当按向上/向下箭头阅读下一行/上一行代码时，在开始说话之前延迟太长(如果乘以 100 毫秒，它会很快变得非常烦人)千百年)。

关于workflow - 失明如何影响您的编码风格？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/47065136/