失明如何影响你的编码风格?[已关闭]

我是一个盲人开发者。我会根据我所做的以及我在其他盲人开发者的代码中已经看到的来回答你的问题。

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

• 不要缩进代码,因为在其中导航和编辑通常会更麻烦,尤其是如果我们想注意不要破坏它。与视力正常的人相反,压痕通常不能帮助我们快速识别障碍。即使我们有盲文显示器,我们一次也只能看到一行。
• 如果有必要,在怀疑的情况下/嵌套很深的情况下,使用其他技巧来确定块的结束位置。最常见的情况是,在结束括号后加上注释,例如:。 } // end for . 当需要这样做时,它可以很好地指示我们应该更好地组织代码/更好地将其分解为不同的功能。
• 使用许多小技巧可以快速跳转到感兴趣的代码部分。这可以是简单的注释,如 //constructor ,可以使用Ctrl+F立即找到,但也可以更精细。例如,我个人的一个技巧是在定义或声明函数时在名称和打开的父级之间留一个空格,但在调用函数时不要这样做。因此,我可以快速转到定义(通过搜索“name(”)或它被调用的位置(通过搜索“name(”)。
• 讨厌ASCII艺术,因为它完全无用,例如:一长串的 /**********
• 经常使用快捷方式来避免没有真实信息的长代码,例如。 import java.util.* 而不是逐个导入50个类。
• 通常更喜欢使用简单的文本编辑器而不是复杂的IDE,或者只将它们用于特定的功能,例如自动格式化,因为这是绝对需要的。这有两个原因:许多IDE是不可访问的,只能部分访问,或者大部分是可访问的,但使用给定的功能并不容易或舒适;或者因为语音和盲文显示的响应性很差,即当按上/下箭头读取下一行/上一行代码时,在开始说话之前会有很长的延迟(如果你将100毫秒乘以1000次,这会很快变得非常烦人)。

嗯,我部分回答了这个问题 here . 基本上,你几乎看不出一段代码是盲人写的,除非他/她以相当粗鲁的方式违反规则(例如,像我一样,在Python中使用制表符和camelCase,而不是空格和snake_case)。
但即使是这些东西也可能只出现在个人的宠物项目或快速而肮脏的脚本中。大多数盲人都承认他们生活在一个有视力的世界里,如果你希望你的pull请求被合并,或者你的代码在工作中被上级审查,那么你可以 必须 无论你喜欢与否,无论你是否失明,都要遵守项目的代码样式。在这种情况下 Go
关于你问题的最后一部分:是的,失明有时会让我选择一种解决方案,即语言。因为我讨厌snake_的情况,我不能考虑在Rust中进行认真的开发,例如,因为(再次)编写这样的代码是一种语言规则。我确实写过Python代码,但它是。。。哦,好吧。。。这是另一件事,因为Python在解决日常问题时是如此快速和灵活,所以我决定在这里处理它(令人讨厌的)多下划线和没有块结束标记的问题。顺便说一句,盲编码器的另一个可能标志是这样的评论: } // end if (在Javascript或C中),或 #end if 作为Python中的一整行。我不否认有视力的人可以使用这些,但是如果你看到每一个if和for,并且在结束时都这样评论,那么很有可能代码是由盲人编写的。我个人不这么做,但我知道人们非常喜欢它。

我知道这个问题很古老,但答案可能仍然相关: 我是一个盲目的开发人员,我总是想遵循一个公司的编码风格或某种语言开发人员给出的标准。

1. 我总是在编写代码时立即缩进代码,屏幕阅读器会报告缩进级别。老实说,我不再有阅读未格式化代码的习惯,但我知道盲人是这样做的;
2. 进行常规docblocking;
3. 当我需要浏览大块代码时,折叠/展开代码的某些部分;
4. 常规蛇/驼鹿的习惯(取决于语言);
6. 试着强迫自己限制一行的长度不超过80个字符,但由于缺乏良好的工具,要确保这一点有点困难;
7. 有时添加一些有用的注释来帮助我调试代码(我指的是注释中的一些计算/公式对其他人来说并不重要,但这取决于具体情况)。 就我个人而言,我发现最大的挑战是在docblocks(注释)中编写代码,例如在Doctrine或APIPlatform中,因为屏幕阅读器读取行中第一个非空格/非制表符字符的缩进,在docblocks的情况下,该字符是星号(*)。