Considering Typehints As Communication

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]).

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

4 thoughts on “Considering Typehints As Communication

  1. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *