静态
类型的引用优点是在编译时捕获了全部错误，这些错误无法到达运行时。例如，如果您有一个静态类型的类或接口作为函数参数，那么您很容易避免意外地传入错误类型的对象（即没有显式和错误的类型转换）。
当然，这不会阻止您传递正确类型的错误对象，也不会阻止您传递给它正确功能但实现错误功能的接口实现。此外，如果您具有100％的代码覆盖率，请说PHP /
Python / etc专家，谁在乎您是在编译时还是在运行时捕获错误？
就个人而言，我在使用静态键入的语言中度过了快乐的时光，而在没有静态键入的语言中则度过了快乐的时光。这几乎不是决定性的问题，因为我从来不必在两种类型相同的语言（除了它们的类型）之间进行选择，而且通常还需要担心一些重要的事情。我的确发现，当我使用静态类型的语言时，我故意“依靠编译器”，试图以这样的方式编写代码：如果出错，它将无法编译。例如，您可以通过在一个位置进行更改，然后修复所导致的所有编译错误来执行某些重构，直到重复进行干净的编译为止。通过多次运行一个完整的测试套件来做同样的事情可能不太实际。但它’
除了便利性和编码风格偏爱以外，还有其他合理的关注事项的人是致力于代码正确性的形式证明的人。我无知的印象是，静态类型推导可以完成显式静态类型所做的大部分（但不是全部）工作，并节省了键盘上的可观损耗。因此，
如果 静态类型迫使人们以一种更易于证明的方式编写代码， 那么
该POV肯定有其特色。我说“如果”：我不知道，而且好像大多数人都不会证明他们的静态类型代码一样。
即时更改变量类型等
我认为这具有可疑的价值。做类似（Python / Django）的东西总是很诱人：
user = request.GET['username']# do something with the string variable, "user"user = get_object_or_404(User,user)# do something with the User object variable, "user"
但是，实际上，是否应该在函数内的不同事物上使用相同的名称？也许。可能不会。例如，对于静态类型语言中的其他事物，“重用”整数变量也不是很受鼓励。不必考虑简洁，描述性的变量名的愿望，大约95％的时间不应覆盖对明确代码的渴望…
顺便说一句， 弱 类型通常意味着隐式类型转换发生，而 强
类型意味着它们不发生隐式转换。根据这个定义，就算术类型而言，C是弱类型的，所以我认为这不是您的意思。我认为，人们普遍认为，完全强类型键入比帮助更麻烦，而“完全弱类型”（任何形式都可以转换为其他形式）在大多数语言中都是荒谬的。因此，存在一个问题，即在您的代码变得难以辨认之前，可以允许多少个隐式转换以及允许哪些隐式转换。另请参阅，在C
++中，决定是否实现转换运算符和非显式单参数构造函数的持续困难。
