女士们先生们,今天我们又来到了花田原创高超开局的当口,有人在质疑《GBC》是否会步入星团的后尘,而我已然在期待下一个《轻音少女》的诞生。在五年后十年后,当新入宅的小鬼们质问在千古名篇《Girls Band Cry》播出那一年我在干什么时,我会骄傲的向所有人说我选择了相信。相信吧,因为相信是不需要理由的。
Tab vs Space
在编程中,Tab 和 Space 用于增加代码可读性的缩进。二者各有支持者:Tab 可以减少文件大小并允许程序员自定义缩进宽度;而 Space 提供了一致的视觉排版,不受编辑器设置的影响。
编码风格指南如 Python 的 PEP 8 推荐使用 4 个空格缩进以维持代码一致性。但在某些情况下,如带有嵌套循环的复杂算法,使用 Tab 可以快速调整整体缩进宽度而不必逐个更改空格。然而,这也可能引发问题,因为不同编辑器/IDE 对 Tab 的解释可能不同,从而影响代码的外观。
在编码协作中,不统一的缩进方式会使得版本控制系统识别正常的缩进更改为代码更改,这会污染提交历史和代码审核。作为解决方案,许多团队选择在项目开始时决定统一使用 Tab 或 Space,以及确定 Tab 键代表的 Space 数。
我就遇到了项目内同时使用 Space 和 Tab 的情况,一度困惑其原因。后发现 VS Code 会通过 Detect Indentation 机制 自动识别并应用文件的缩进格式。所以不同的同事开发同一个仓库的不同文件时,可能就因为编辑器的初始缩进配置不一样,就会出现上面的乱象。
本来想将 Detect Indentation 关掉统一设置成 4 Space 的,但不是所有项目可以由我决定的,而且会将历史的更改记录给污染了,这种情况还是保守一点入乡随俗吧。而我可以控制的项目都统一改成 4 Space !
PS. Stack Overflow 的一个 著名调查表明,使用 Space 缩进的程序员可能平均薪酬要略高于使用 Tab 的程序员,但这并不意味着 Space 直接导致了薪酬的差异。这可能是由于使用 Space 的程序员往往遵循的是某些广泛接受的编程约定。
🔗Tabs versus spaces - Stack Overflow | #编程#缩进#代码风格#TIL
Putting things in perspective has been another big one for me. I always ask myself, "Will this matter in two years?" You'd be surprised how often the answer is no. It takes the edge off the pressure. I allow myself to miss a deadline every now and then. As I mentioned above, not every deadline is do-or-die. Sometimes, it’s entirely reasonable to push things back to worry less.
The world is full of people who disagree with you, but you need to learn more than ever to recognize and filter out what you don't care about. I don't even view replies to posts any longer, 98% of the time because I am not seeking validation sharing my opinion.