引用的静态类型的优点是在编译时遇到了整个错误类,无法到达运行时.例如,如果你有一个静态类或接口作为一个函数参数,那么你不会意外地传入错误类型的对象(没有显式和不正确的转换,也就是).
当然,这并不阻止你传递错误的对象,正确的类型,或一个接口的实现,你给它正确的功能,但他们做错了的事情.此外,如果您有100%的代码覆盖率,请说PHP / Python / etc等人,谁关心您是否在编译时或运行时捕获错误?
就个人而言,我在有静态打字的语言中玩得很开心,而且在没有语言的情况下玩得很开心.这很少是决定性的问题,因为我从来没有选择两种语言,而不是他们的打字类型,而通常更重要的事情要担心.我发现当我使用静态类型语言时,我故意“依靠编译器”,试图用这样的方式编写代码,如果它是错误的,它将不会编译.例如,有一些重构器可以通过在一个地方进行更改来执行,然后修复导致的所有编译错误,重复直到清除编译.通过多次运行完整的测试套件来做同样的事情可能不是很实用.但是IDE不会让其他语言自动化相同的重构器,也不能快速完成测试,所以这是一个方便的问题,而不是可能的.
具有方便性和编码风格偏好的合法关注的人是正式证明代码正确性的人.我的无知的印象是,静态类型的扣除可以做大部分(但不是全部)显式静态打字所做的工作,并且在键盘上节省相当的磨损.所以如果静态打字迫使人们以更容易证明的方式编写代码,那么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%的时间不应该超越对明确代码的渴望…
Btw通常是弱类型意味着隐式类型转换发生,强类型意味着它们不会.通过这个定义,C对于算术类型是弱类型,所以我认为这不是你的意思.我认为广泛认为,强力打字更是一个烦恼,而不是一个帮助,而且“全弱的打字”(任何东西都可以转换成别的东西)在大多数语言中是荒谬的.所以问题在于您的代码太难以弄清楚,可以容忍多少隐含的转换.另见在C中,决定是否实现转换运算符和非显式单参数构造函数的持续困难.