副标题：让工具帮助你，摒弃旧有的编码心态
发布时间：2020年9月6日 - 5分钟阅读
照片：Kaitlyn Baker on Unsplash
最近我写了一篇关于我们的编码风格是如何由于编程语言的进化和工具（如IDE）的进步而进化的。
我本来是坚信他们的，但现在我已经改邪归正了。
并非所有人都同意我们的编码方式应该受到IDE的影响。我可以理解这一点的由来，也同意完全依赖一些工具来完成工作并不理想。尽管如此，我不能否认这些工具是如何影响了我的编码方式，就像Vim和Emac对于其他一些人一样。
不需要一开始就有完美的代码组织
我记得在我们开始一个项目之前的那些日子里，开了一个又一个的会议，写了一份又一份的文档，讨论一个新项目的理想代码组织应该是什么。预测项目将如何发展。所有这些都是因为我们要避免未来在代码base上的改动，因为以后再改会很困难。 有了IDE，我们可以轻松地移动类，重命名它们，代码会自动重构在一起。对于开发者来说，几乎没有什么麻烦，可以去到处搜索，手动修改它们。
例IDE功能，可以更改文件类名，一切都可以一起更改。
有了能够让修改变得更容易，我们现在可以不用太担心我们的初始结构不理想，名字不够好等等，也不用担心他们是作为未来主义的证明，因为反正没有人知道未来。以后的改变不再是那么艰巨的任务。
说到这里，我不得不声明，要想让代码结构合理，尽可能给它们起一个有意义的名字，需要一些尽职调查。这绝不是忽视这一点的借口。只是我们现在可以避免偏执于最初的设计要到位，这样才能有更快的初始交付。
编码审查的重点是语义而不是语法
我第一次在软件机构工作时，我们在一个房间里进行代码审查。我们把代码打印回来，按照编码指南阅读，查找代码的错位。我通常会寻找诸如未使用的导入，错误的{起点，使用空格而不是tab，等等（没有对齐缩进）。
换句话说，我关注的是代码结构，而不是代码的含义。这些在当时是很重要的，因为它有助于让代码更 "可读"。 今天，我已经很少关注这些方面了，而是更关注代码的业务逻辑（例如，一个变量是否应该可空）。原因很简单，工具帮助我们发现了一些基本的代码问题，并为我们改进了这些结构。
如：工具自动推荐下面的变量可以是私有的。
作为安卓工作室的用户，这是很基本的事情，但我却经常忘记自己。而且还经常发现一些别人...
通过工具自动化辅助，可以轻松纠正结构和命名习惯不良的可能性。
比起全面的代码，更喜欢简洁的代码
在过去，代码必须尽可能的全面，以确保其可维护性。这里的全面是指，在第一次看到代码时，它应该有尽可能多的信息，如
- 对于复杂或特殊的情况，应该有编码注释。
- 前置的命名惯例来显示类型，例如：
mMemberVariable。 - 参数命名，例如
download(url = URL, file = targetFile)
这些都是过去的惯例，在工具中审查代码，团队中不是每个人都有相同的IDE。但如果大家共享同一个工具集，那么我们就可以专注于更简洁的编码，而不是明确地礼仪性地写下一切。
例如
明确的代码注释不需要
人们可以很容易地提取git提交信息，找到相关的提交信息。这些就会更好的反映出代码的变化。最重要的是，如果做了进一步的修改，我们不再担心注释与代码不同步了。
基于前缀的文本命名惯例不需要。
基于文本区分变量类型，因为语法着色现在在所有IDE源代码查看器中都是默认的。
不需要明确的参数命名
在IDE中，我们就可以直接点过去，得到所有的函数类型，这样就可以清楚的说明函数的参数。
我不再需要download(url = URL, file = targetFile)的代码。
注：这是假设整个团队工作的代码需要使用名工具集（如IDE），并有能力对它们进行相应的审查。
无论如何，我相信简洁的编码是未来的趋势，按照下面的博客。
几十年的小事之争，还会结束吗？
边编码边学习
历史上人们必须研究有哪些API，所以确保我们使用正确的API。虽然这仍然是非常正确的，但今天的IDE也帮助我学习。
显示可用的API
有了AutoComplete功能，我只需要输入和搜索一下，就能找到该特定对象的API。
学习新的API
我不仅可以看到哪些API是可用的，而且还可以轻松地访问API的文档。下面是一个例子，提供了所有的描述和图表。
throttleFirst功能的描述。
建议更好的编码或API用法
下面是一个例子，我使用filter { it is Int }，最好用filterIsInsance<Int>()代替。IDE推荐我使用这个方法。
以上是IDE在日常编程工作中给我带来巨大帮助的几个例子，除了基本的Code、Compile和Debug，IDE一直在做。它使我们能够做出更快的开发，也放弃了一些旧的关注方式而采用新的开发方式。
