Typehints help communicate across time and space, to people who may never meet you or who might not be able to interrogate you about your code, so those people can understand how you expect the code to work.
Adding typehints is a succinct, more-complete form of communication than not-adding them. (It is rare, perhaps impossible, for all communication can be fully complete all the time.)
Further, you don’t know in advance which parts of the codebase are going to last for a long time, and which are going to be replaced in relatively short order. It’s probably better to to add the typehints when you know what they are, rather than to wait and see if you’ll “need” them later.
Typehints can be considered low-cost mistake-proofing against misunderstanding in an obvious place (i.e., where they are used), without having to look elsewhere (“just read the tests!” [groan]).
I couldn’t agree more. We added tons of doc block type hints when we started using PhpStorm a couple of years ago. It was very helpful.
We are at this very moment we are working on a bunch of stories to add PHP 7.1’s new language-level type hints to our code.
It’s awesome to be able to look at the signature of a method and know that it is only going to accept whatever we hint or can be coerced to our hint or an exception will be thrown.
I find it especially helpful as a sort of ‘step 0’ for monster methods with lots of parameters that I don’t have time to refactor at the moment.
[…] Source link […]
[…] 注意，这里我们声明了使用严格模式 —— 作为最佳实践，你应该在应用程序的 每个 PHP 文件的开头 都这样做。因为对从你后面来的开发者来说类型提示对 调试和清晰的交流意图很重要 。 […]
[…] 注意，这里我们声明了使用严格模式 —— 作为最佳实践，你应该在应用程序的 每个 PHP 文件的开头 都这样做。因为对从你后面来的开发者来说类型提示对 调试和清晰的交流意图很重要 。 […]