Typescript 中的类型推断与显式类型声明

我遇到过几个不同的代码实例，其中变量使用显式类型声明，即使推断的类型很明显：

例子：loading: boolean = false or name: string = "John" or count: number = 0 etc.

TSLint 更喜欢推断类型而不是显式类型，所以我想知道这只是一个风格问题吗？这些显式类型在运行时是否重要？

今天的大多数 javascript 社区可能会支持推理，因为类型推理在某种程度上更容易阅读（即更少的字母），但易于阅读不仅仅是更少的阅读。较少的字母对于程序简单性来说是一个不精确的衡量标准，请考虑：

I hp I mk m slf clr vs I hope I make myself clear

保持开放的态度，尝试这两种方法，才能形成强烈的意见。但要保持灵活性，不要让你的意见妨碍你。

请记住

当我没有做足够的研究时，我的观点就是我的观点

如果您了解一项决定相对于另一项决定的后果，那么您不需要意见，您只需选择一个更可取的选项即可。在这种情况下，您可以将自己从决策过程中解放出来，让常识或逻辑来决定您编写的代码的实际形状。它可能会让你在以后的某个时候免于通过说“我是一名艺术家，我这样看待事物”来为自己辩护。

这种思路清楚地表明了为什么在大多数情况下支持团队的决策是一个好主意。

拖延并等待运行时出现错误是个坏主意，因为你的程序没有理由实际上因异常而在痛苦中死亡。在提交和部署代码之前识别错误要快得多，成本也要低得多，因为在创建票证、规划票证、调查或共享知识以及修复票证方面，需要团队投入更多资源来进行上下文切换。同样，从业务角度来看，不犯错误更便宜，因为每个错误都可以用收入损失来衡量，所以考虑运行时检查作为一种选择的赌博有什么意义呢？只要确保您的类型精确且广泛即可。

这就是我个人倾向于更喜欢显式类型的原因。我的优点和缺点清单告诉我，类型不是内衣，所以没有必要隐藏它们。静态类型系统对齐正式的数学证明，证明您的程序是正确的。它的存在是有原因的——支持你的类型系统，它也会支持你作为回报。不要偷懒地用类型来修饰变量。即使类型声明看似被省略，提供类型名仍然是一个好主意。

因类型系统的缺乏或不完善而给公司和项目造成数十亿损失的情况屡见不鲜。

即使您的编译器检查不够严格（即数字并不总是您可能期望的数字，考虑以下内容），眼前有一个类型名称可以帮助您再次思考并避免犯错误案件：

const x: Miles = 3;
const y: Kilometers = 5;
...
const result = x + y; // Result type is obviously unknown so the operation shouldn't be implicitly allowed

如果您的类型变得太大或太复杂而无法每次都编写，则暗示您是时候对此采取措施了。

但谁知道我可能是错的，就像任何人一样......