今天的javascript社区大多数人可能会支持类型推断，因为类型推断在某种程度上更容易阅读（例如，更少的字母），但易读性不仅仅是更少的阅读，更少的字母是程序简单性的一个不精确的度量标准。
I hp I mk m slf clr与I hope I make myself clear
开放一点，尝试两种方法都能让你得到一个强有力的观点，但是要灵活，不要让你的观点阻碍你。
记住
当我没有做足够的研究时，我只有一种观点
如果你明白一个决定的后果，你就不需要别人的意见，你只需要选择一个更好的选项。在这种情况下，你把自己从一个决策过程中排除出去，让一个常识或逻辑来支配你所写代码的实际形状。这可能会让你在以后的某个时间点上不必为自己辩护，比如说"我是一个艺术家，我是这样看待事情的"。
这种思路使我们明白为什么在大多数情况下支持团队的决策是一个好主意。
拖延和等待错误在运行时弹出是个坏主意，因为没有理由让你的程序因为异常而痛苦地死去。在提交和部署代码之前识别错误要快得多，也便宜得多，因为它会从你的团队中花费更多的资源来进行上下文切换，比如创建票证、计划票证、调查或分享知识，并修复它们。同样，从商业Angular 来看，不犯错误更便宜，因为每个bug都可以用收入损失来衡量，那么考虑运行时检查的赌博作为一种选择有什么意义呢？只要确保你的类型是精确和广泛的。
这就是为什么我个人倾向于选择显式类型的原因。我的优点和缺点列表告诉我类型不是内衣，所以没有必要隐藏它们。静态类型系统与你的程序正确的正式数学证明保持一致。它存在是有原因的--支持你的类型系统，它也会支持你。不要懒惰地用类型来装饰变量。即使类型声明似乎被省略了，提供一个类型名仍然是一个好主意。
在许多情况下，由于类型系统的缺乏或不完善，给公司和项目造成了数十亿美元的损失。
在你眼前有一个类型名可以帮助你触发第二个想法，避免你犯错误，即使你的编译器没有严格到足以检查（即一个数字并不总是你所期望的数字，考虑以下情况：

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

如果你的类型变得太大或太复杂以至于每次都写不出来，这是一个提示，告诉你是时候做点什么了。
但谁知道我可能错了，就像其他人一样...

在你的例子中，这只是风格的问题，因此，从编译的Angular 来看，它对你的代码没有影响。注意，这是针对变量值显式定义其类型的情况，这可能会使你的代码在从其他变量中重新赋值的情况下变得复杂。
换句话说，你这样做可能更好：

name: string = "John"
bday: Date = "1980/01/10" //the compiler says there is an error

并避免：

name = "John"
bday = "1980/01/10" //no compiling error, but it should be new Date("1980/01/10")

注意：未定义的类型将始终被视为任意类型。

声明的类型在运行时根本不重要。当Javascript生成时，所有类型都将被删除，因为Javascript不支持指定变量类型。
至于为什么TSLint更喜欢类型推断而不是显式类型，我会说这可能是为了保持干燥（不要重复自己）。因为编译器可以为您进行类型输入，所以没有理由向代码添加更多噪音。

从Should you annotate or let TypeScript infer the types?开始
对于是否注解代码，最好的一般准则是你注解的表达式/变量是否是一个"边界"。边界通常指的是你的各种模块的导出函数/类等。对于这些，你可能希望明确你期望的是什么，以使你的API更清楚。
但是，特定模块的内部函数和变量可能不需要注解
从When to add types and when to infer in TypeScript
向所有函数声明添加类型。
不向变量添加显式类型
从https://www.schibsted.pl/blog/typescript-type-inference/开始
"理想的TypeScript代码包括函数/方法签名的类型注解，但不包括在其主体中创建的局部变量的类型注解。这样可以将干扰降到最低，并使读者能够专注于实现逻辑"。