我已经在SO中搜索了该问题的综合答案，但似乎找不到任何答案，因此，我希望能获得关于在Typescript和Javascript中插入应用程序的好处的综合答案，或一个链接的答案这样。
自从我开始编写Typescript代码以来，我一直在整理应用程序，而整理对我来说是常识，编写干净的代码有一种很好的感觉。但是，我偶然发现TypeScript代码充满了掉毛错误，并且我的代码编辑器每两行都有错误。显然，这感觉并不好，但是我想知道为什么建议在发货之前准确地抹掉JS / TS应用程序，尤其是因为我目前必须处理的应用程序似乎从未经过TS掉毛错误检查，他们工作没有任何问题？仅仅是因为它很干净还是具有任何性能或其他优点？
答案 0 :(得分：1)
林特犬的存在是根据社区整体，尤其是林特犬的创建者的多年经验来指出常见的潜在问题代码模式。如果需要出于某种原因在特定项目中实施自定义约定，那么大多数随身携带的物品也可以使用自定义规则进行扩展。
可能有问题并不意味着代码在特定情况下会实际上产生错误。但是避免这种潜在问题，转而使用已知的更好模式肯定更好。短绒通常是非常保守的，这并不意味着保守的代码不能工作。但是不要抱怨没有人告诉过你，如果你冒险进入这样的领域并产生错误。
答案 1 :(得分：1)
我喜欢https://www.jslint.com/help.html的基本原理：
如果某个功能有时有用而有时又很危险，并且有更好的选择，那么请始终使用更好的选择。
...
当C是一种年轻的编程语言时，原始编译器并未捕获一些常见的编程错误，因此开发了一个名为lint的辅助程序，该程序将扫描源文件以查找问题。
随着语言的成熟，...编译器在发出警告方面变得更好。不再需要棉绒。
JavaScript是一种年轻的语言。它原本打算在网页中执行小任务……当项目变得复杂时，许多旨在使该语言易于使用的功能很麻烦。需要皮绒的JavaScript ...
恕我直言，下一代短绒棉（例如 15:29:22.258 [Task worker for ':'] ERROR o.a.i.h.AndroidManifestFinder:148 - Could not find the AndroidManifest.xml file, using generation folder [D:\Workspace\refcom4all-android\app\build\generated\source\apt\debug])
）采用了这一核心理念，但用可配置的选项代替了一些强烈的观点，以扩大受众范围。框架插件增加了。选项已添加到地址代码格式中，而不仅仅是潜在的危险功能。人们不同意某些选择，自以为是的格式化者找到了自己的定位（例如eslint）。
Typescript似乎实现了最重要的代码质量规则，将其作为编译器核心的一部分，而更具争议性的规则留给了决定实施一致代码风格的团队（例如prettier）（以提高可读性，...）。
不确定多少一致的代码样式可以提高代码质量，但是我有理由相信它不会降低质量，并且可能会带来巨大的收益（如果我发现有关该主题的值得信赖的研究，我将添加到此答案中。）