代码编辑器设计思考_关于代码完成的一些思考

代码编辑器设计思考

在对程序员沉迷于代码完成的含义进行一些哲学思考之前，请先对我的道路进行一些观察。

2003年，我开始使用Eclipse。 在此之前，我经常使用JBuilder。 Eclipse宣称，增量编译是未来，任何不使用增量编译的人都会迷失方向。 您会在键入时看到错误。 我记得当时对那种前景并不感到兴奋，但是随着时间的流逝，我确实发现，有了Eclipse，我能够使环境变得非常快。 当我首先在WTP项目发布之后发布残废版本，然后在采用Maven之后，那里的插件情况开始产生st头的癫痫病般的疯狂，这让我的爱慕开始动摇了。 另外，我必须尝试Xcode，然后，哇，我想：“如果只有更多的东西，尤其是TDD东西，它就会变得更快，更干净。” 好吧，现在有了这些东西，毫无疑问， 恕我直言 ，这是最好的IDE 。 当然，我不能用它或Web东西来编写大数据程序，但是对于移动设备和应用程序来说，这很麻烦。

最近，根据我这里冗长的“文档”，我一直在使用IntelliJ，首先是Android Studio的一部分，然后是使用Play和Akka的项目。 因为它太慢了，所以把我赶走了。 我受不了它的工作。 我更喜欢仅跳至控制台并进行测试。 它也确实很愚蠢，很容易弄乱，然后，如果我更改项目中的内容，则必须重新生成项目文件，这似乎使尿布面色苍白，我什至无法真正说出它的感觉。 无论如何，我认为IntelliJ已经轻易击败了Eclipse。 它的“实时模板”比eclipse的模板要好得多，自我开始使用eclipse以来的10年中，eclipse的模板就没有发展过一次（请注意，它的含义不仅仅是微小的改进）。

最近，我重新回到Sublime Edit。 原因是因为我在使用Bootstrap并在某个地方碰到它，然后我看到了本教程，并且有点________（沿着吹牛的线插入您喜欢的短语）。 首先，这件事太蠢了。 其次，本教程向您展示了非常有趣的事情。 我开始想象，如果我将它用于Play或Akka，我会错过什么？ 当然，答案很快就会回来：代码完成。

代码完成非常棒，自从它进入开发以来，我就对它充满了爱和赞美。 但是，今天，我正在考虑它，然后开始思考，它很像婴儿。 就像IDE在台下一样，诱使婴儿张开嘴，把每个切块都放进去，然后在咀嚼完之后再要求更多。 现在，与此相反的论点是，由于C ++ / Java灾难，我们生活在一个始终使用数百种API进行编程的世界中。 我最近一直在使用Hadoop。 这是OSS产生的一个完美示例：一个巨大的，杂乱无章的n子，另一个需要填隙的小裂缝的另一个项目。 Xcode和Apple之所以如此高兴的原因之一是，您可以学习一个框架，然后将其用于大多数编码中，而不必不断地进出大量实践不同约定且没有概念的小型机智伪框架。绑定逻辑（毕竟他们不知道您还和谁一起工作）。

所以我开始思考，我可以在Sublime中进行一些编码吗？ 那会是什么样？ 在开发环境中，我最重要的是TDD的速度。 最重要的是，然后是代码完成。 但我认为，没有它，可能会有生活的方式。

施工阶段

如果您考虑一下，确实需要代码完成，原因有两个：

• 您要么不熟悉所用事物的API
• 您不熟悉，因为它的设计不当并未能通过启发式挑战

您如何看待这种情况的蔓延？ 我会说至少80％的案件包含b。 例如，没有一个理智的人会争论Joda比JDK的时间/日期功能更好的事实。 但是，从启发式分析的角度来看，我不认为Joda是一个不错的API ，因为我已经无数次地使用了它，而且我永远也不会记得它所有的古怪愚蠢。 我什至不记得它的概念，是的，即时，持续时间等，但是它们如何将这些概念映射给我，并不好，也不会留下持久的印象。

因此，现在我们要说的是婴儿必须减少食物摄入量，因为每个人的狂野西部都能获得API的心得分享，这意味着您永远不会几乎不知道自己在使用什么。

让我暂停一下，以注意到这种情况的巨大悲剧。 其宇宙悲剧性的主要原因是AFAIC ，这也许是对象应该执行结构化编程（方法）所不能做的主要事情：随着函数变得越来越复杂，它们的签名超出了7 +/- 2范围（一个人可以保持多少个并发概念）以及实现任何一种流利性的能力就消失了。

我之前曾提出过这种说法，但是现代版本的Objective C的真正天才在于，通过类别及其更新的表示法（尤其是文字），它的意思是“让用户协商使事情变得更有用的最后一步。 。 而且其中有很多智慧，因为启发式方法通常会受到需求的影响！ 我不想随身携带大量行李，而我只需要一小部分。

另一个可能的解决方案是我最喜欢的强迫模式：Builder。 Bloch的“静态生成器”模式在很大程度上使复杂的结构更加流畅且易于导航。 现在，Builder也是完美的代码补全对象 ，因为链接此引用使您可以一直下去。 并选择另一种方法。 ST中可能的解决方案是仅在构建器用户插件中编程，该插件将读取类，获取构建器并解析它们，然后提出方法。 或者，可能只有在某种侧边栏配置中打开一个窗口才有意义，并且当您开始进行构造或调用某些东西的过程时，它会出现在该窗口或它的文档中，或者可能同时出现在这两个窗口中。

Cocoa是最古老，最成熟的框架之一，总的来说，使用它时，代码完成并没有真正改变太多。 部分原因是该方法易于记忆，例如ViewDidLoad或ViewWillAppear。 而且，由于使用了很多次，因此您学习了它，然后并不需要太多帮助。

显然，任何对此类型的精益意识都必须看到，在这种情况下，最好的情况只是权衡：程序员花了更少的时间寻找方法调用，但是随后，在IDE中运行并重新运行测试太慢了，那些储蓄已经/将被放回池中100倍以上。 人们曾经开玩笑说C ++是包装语言。 如果包装程序保持流畅，那么包装程序就不是一件坏事，尤其是在一个长期的项目过程中会产生大量流量的关节上。

对IDE来说，代码完成就像对PC一样，对Outlook来说就是代码完成：一个船锚，即使人们从无数其他方向取水，也可以鼓励人们呆在船舱中。 直到可以使用本机出色的IDE进行Web开发之前，寻找内联代码完成的替代方法可能是最好的解决方法。

翻译自: https://www.javacodegeeks.com/2014/06/a-few-thoughts-on-code-completion.html

代码编辑器设计思考