失明如何影响你的编码风格？
How does being blind affect your coding style?
how blind people program 的问题已被反复回答，但我找不到任何关于失明和使用屏幕 reader 或盲文显示器如何影响您的编码风格的信息。
你能区分盲人创建的代码和其他代码吗？
失明是否会让您对问题产生不同的看法并寻找其他解决方案？
嗯，我部分回答了这个问题。基本上，你很少能分辨出一段代码是由盲人编写的，除非 he/she 以相当粗鲁的方式违反规则（例如，使用制表符和驼峰式而不是空格和 snake_case 在 Python，像我一样）。
但即使是这些东西也可能只在个别的宠物项目或快速而肮脏的脚本中看到。大多数盲人都承认他们生活在一个有视力的世界中，如果您希望您的拉取请求被合并或您的代码被工作中的上级审查，您必须遵守代码项目的样式，无论您喜欢与否，无论您是否盲目。在这种情况下，Go 的人们做出明智的决定，包括每个 Go 开发人员在提交 his/her 代码之前必须 运行 的格式化实用程序。 "Nobody likes the Gofmt style"，Rob Pike 说，他错了：我非常喜欢它的风格：驼峰式和制表符，多么美味的东西！但即使您不喜欢它，您也必须 运行 这个工具，因为这是语言规则。
对于你问题的最后一部分：是的，失明有时会让我选择一种解决方案，即一种语言。因为我讨厌 snake_case，所以我无法考虑在 Rust 中进行认真的开发，例如，因为（再次）编写这样的代码是一种语言规则。我确实写了 Python 代码，但它是......哦好吧......有点像其他事情，因为 Python 在解决日常问题方面是如此快速和灵活，所以我决定在这里处理它（烦人）多个下划线和没有块结束标记。顺便说一句，编码盲人的另一个可能标志是这样的注释：} // end if（在 Javascript 或 C 中），或 #end if 作为整行 Python。我不否认有视力的人可以使用那些，但是如果你看到每一个 if 和 for 以及 while 结尾都这样评论，那么代码很有可能是由盲人编写的。我个人不这样做，但我知道有人非常喜欢它。
我是盲人开发者。我将根据我所做的以及我在其他盲人开发人员的代码中已经看到的内容来尝试回答您的问题。
但是，请记住，我的回答绝对不是参考。可能有许多不同的用法、习惯和偏好，就像有视力的普通开发人员一样。
在一家公司 and/or 为开源项目工作时，我们无论如何都必须按照给定公司 and/or 项目的规则定义我们的代码格式。毫无疑问，这是必需的。
在这种情况下，我和我认识的大多数盲人程序员首先编写未格式化的代码、编译、测试等，只有在提交时才对其进行格式化。
IDE中的自动格式化工具非常珍贵，否则往往会很痛苦。如果不使用 IDE，命令行工具也很常见，例如Java 和 C/C++ 的 astyle。
如果公司 and/or 项目不需要给定格式，我们中的许多人：
- 不要缩进代码，因为在代码中导航和编辑通常会更痛苦，尤其是当我们想注意不要破坏代码时。与有视力的人相反，缩进通常不能帮助我们快速识别块。即使有盲文显示器，我们一次也只能看到一行。
- 如果有疑问/嵌套很深，必要时使用其他技巧来确定块的结束位置。大多数情况下，这采用右括号后的注释形式，例如
} // end for。当需要这样做时，它可以是一个很好的指标，告诉我们应该更好地组织代码/更好地拆分成不同的功能。
- 使用很多小技巧可以快速跳转到感兴趣的代码部分。这可以是像
//constructor 这样的简单注释，可以使用 Ctrl+F 立即找到，但也可以更微妙。例如，我的个人技巧之一是在定义或声明函数时在名称和开放父级之间放置 space，但在调用函数时不要这样做。所以我可以快速转到定义（通过搜索"name ("），或者调用它的地方（通过搜索"name("）。
- 讨厌 ASCII 艺术，因为它完全没用，例如：一长串
/**********
- 经常使用快捷方式来避免没有提供真实信息的长代码，例如
import java.util.* 而不是一一导入 50 类。
- 通常更喜欢使用简单的文本编辑器而不是复杂的 IDE，或者只将它们用于自动格式化等特定功能，因为这是绝对需要的。造成这种情况的两个原因：许多 IDE 无法访问，只能部分访问，或者大部分都可以访问，但使用给定功能不一定容易或舒适；或者因为语音和盲文显示器的响应很差，即当按 up/down 箭头阅读 next/previous 行代码时，在它开始说话之前有太长的延迟（它很快变得非常烦人，如果你将 100 毫秒乘以一千次）。
我知道这个问题很老了，但答案可能仍然相关：
我是盲人开发者，我总是想遵循公司的编码风格或语言开发者给出的一些标准。
- 我总是在编写代码时立即缩进代码，屏幕 reader 会报告缩进级别。老实说，我不再有阅读未格式化代码的习惯，但我认识一些盲人；
- 进行常规文档屏蔽；
- Fold/unfold 当我需要浏览大块代码时的某些部分；
- 常规蛇形/驼形习惯（取决于语言）；
- 有时写更长的代码行然后使用IDE来修复格式，因为并不总是更长的代码对我来说阅读起来更复杂；
- 尝试强制自己将一行的长度限制在不超过 80 个字符，但由于缺乏良好的工具，确保发生这种情况有点痛苦；
- 有时添加一些有用的注释来帮助我调试代码（我的意思是注释中的一些计算/公式对其他人来说不一定重要，但这取决于）。
我个人发现最大的挑战是在文档块（注释）中编写代码，例如在 Doctrine 或 APIPlatform 中，因为屏幕 reader 读取第一个非 space / 非制表符的缩进在文档块的情况下是星号 (*) 的行。
how blind people program 的问题已被反复回答，但我找不到任何关于失明和使用屏幕 reader 或盲文显示器如何影响您的编码风格的信息。
你能区分盲人创建的代码和其他代码吗？
失明是否会让您对问题产生不同的看法并寻找其他解决方案？
嗯，我部分回答了这个问题
但即使是这些东西也可能只在个别的宠物项目或快速而肮脏的脚本中看到。大多数盲人都承认他们生活在一个有视力的世界中，如果您希望您的拉取请求被合并或您的代码被工作中的上级审查，您必须遵守代码项目的样式，无论您喜欢与否，无论您是否盲目。在这种情况下，Go 的人们做出明智的决定，包括每个 Go 开发人员在提交 his/her 代码之前必须 运行 的格式化实用程序。 "Nobody likes the Gofmt style"，Rob Pike 说，他错了：我非常喜欢它的风格：驼峰式和制表符，多么美味的东西！但即使您不喜欢它，您也必须 运行 这个工具，因为这是语言规则。
对于你问题的最后一部分：是的，失明有时会让我选择一种解决方案，即一种语言。因为我讨厌 snake_case，所以我无法考虑在 Rust 中进行认真的开发，例如，因为（再次）编写这样的代码是一种语言规则。我确实写了 Python 代码，但它是......哦好吧......有点像其他事情，因为 Python 在解决日常问题方面是如此快速和灵活，所以我决定在这里处理它（烦人）多个下划线和没有块结束标记。顺便说一句，编码盲人的另一个可能标志是这样的注释：} // end if（在 Javascript 或 C 中），或 #end if 作为整行 Python。我不否认有视力的人可以使用那些，但是如果你看到每一个 if 和 for 以及 while 结尾都这样评论，那么代码很有可能是由盲人编写的。我个人不这样做，但我知道有人非常喜欢它。
我是盲人开发者。我将根据我所做的以及我在其他盲人开发人员的代码中已经看到的内容来尝试回答您的问题。 但是，请记住，我的回答绝对不是参考。可能有许多不同的用法、习惯和偏好，就像有视力的普通开发人员一样。
在一家公司 and/or 为开源项目工作时，我们无论如何都必须按照给定公司 and/or 项目的规则定义我们的代码格式。毫无疑问，这是必需的。 在这种情况下，我和我认识的大多数盲人程序员首先编写未格式化的代码、编译、测试等，只有在提交时才对其进行格式化。 IDE中的自动格式化工具非常珍贵，否则往往会很痛苦。如果不使用 IDE，命令行工具也很常见，例如Java 和 C/C++ 的 astyle。
如果公司 and/or 项目不需要给定格式，我们中的许多人：
- 不要缩进代码，因为在代码中导航和编辑通常会更痛苦，尤其是当我们想注意不要破坏代码时。与有视力的人相反，缩进通常不能帮助我们快速识别块。即使有盲文显示器，我们一次也只能看到一行。
- 如果有疑问/嵌套很深，必要时使用其他技巧来确定块的结束位置。大多数情况下，这采用右括号后的注释形式，例如
} // end for。当需要这样做时，它可以是一个很好的指标，告诉我们应该更好地组织代码/更好地拆分成不同的功能。 - 使用很多小技巧可以快速跳转到感兴趣的代码部分。这可以是像
//constructor这样的简单注释，可以使用 Ctrl+F 立即找到，但也可以更微妙。例如，我的个人技巧之一是在定义或声明函数时在名称和开放父级之间放置 space，但在调用函数时不要这样做。所以我可以快速转到定义（通过搜索"name ("），或者调用它的地方（通过搜索"name("）。 - 讨厌 ASCII 艺术，因为它完全没用，例如：一长串
/********** - 经常使用快捷方式来避免没有提供真实信息的长代码，例如
import java.util.*而不是一一导入 50 类。 - 通常更喜欢使用简单的文本编辑器而不是复杂的 IDE，或者只将它们用于自动格式化等特定功能，因为这是绝对需要的。造成这种情况的两个原因：许多 IDE 无法访问，只能部分访问，或者大部分都可以访问，但使用给定功能不一定容易或舒适；或者因为语音和盲文显示器的响应很差，即当按 up/down 箭头阅读 next/previous 行代码时，在它开始说话之前有太长的延迟（它很快变得非常烦人，如果你将 100 毫秒乘以一千次）。
我知道这个问题很老了，但答案可能仍然相关： 我是盲人开发者，我总是想遵循公司的编码风格或语言开发者给出的一些标准。
- 我总是在编写代码时立即缩进代码，屏幕 reader 会报告缩进级别。老实说，我不再有阅读未格式化代码的习惯，但我认识一些盲人；
- 进行常规文档屏蔽；
- Fold/unfold 当我需要浏览大块代码时的某些部分；
- 常规蛇形/驼形习惯（取决于语言）；
- 有时写更长的代码行然后使用IDE来修复格式，因为并不总是更长的代码对我来说阅读起来更复杂；
- 尝试强制自己将一行的长度限制在不超过 80 个字符，但由于缺乏良好的工具，确保发生这种情况有点痛苦；
- 有时添加一些有用的注释来帮助我调试代码（我的意思是注释中的一些计算/公式对其他人来说不一定重要，但这取决于）。 我个人发现最大的挑战是在文档块（注释）中编写代码，例如在 Doctrine 或 APIPlatform 中，因为屏幕 reader 读取第一个非 space / 非制表符的缩进在文档块的情况下是星号 (*) 的行。