Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

davestewart's avatar

Contract naming conventions (edited)

I've edited my previous question to make it shorter:

Why does Laravel's contracts implementation not follow the generally-accepted Interface naming convention?

  • ThingInterface
  • IThing
  • iThing

In type-hinted methods, it makes working out if you're working with an Interface or a concrete class less obvious than it could be, and when combined with the hoops one has to jump through to implement dependency injection, and the splitting of functionality into multiple service providers, often I've really no idea where particular functionality is coming from.

Is there a reason, other than to "look" nicer?

And does anyone have any tips or suggestions on how to get better at mentally managing / physically navigating all this invisible wiring?

0 likes
5 replies
davestewart's avatar
martinbean's avatar

@davestewart Because it was a choice made by the framework author. No other reason than that. Guidelines are exactly that: guidelines.

davestewart's avatar

Sure, I get that @martinbean

I've just taken some time out to re-read through the first thread I posted above.

@thepsion5's post mentioned:

I use to append Interface to my interfaces, but I've found that it's not terribly intuitive, especially for typehinting. Mentally, it's easier for me to parse someFunction(UserRepository $users) than someFunction(UserRepositoryInterface $users). Not by a lot, but it adds up over time, especially when I'm dealing with a really complex applications.

I agree with him that appending Interface (even though it's the preferred PHP convention) feels cumbersome in type hinting:

someFunction(UserRepositoryInterface $users) { ... }

The main alternative offered by a few posters, initially @RayRutjes was to alias classes on import:

use UserRepositoryInterface as UserRepository;
someFunction(UserRepository $users) { ... }

That's seems like the best approach to balance explicitness with expressiveness.

Though as a one-liner, I still like the I-prefix:

someFunction(IUserRepository $users) { ... }

Whether or not I use that in my own code remains to be seen. Generally when using a new language or framework I like to work with the best practices as laid down by the framework or author (as you mentioned) as I find it the best way to make your code portable to other people.

As my last question mentioned, I'm also looking for tips on how to manage this, but I guess perhaps it will just come down to experience.

martinbean's avatar

@davestewart The ‘I’ prefix (i.e. IUserRepository) has never really been a PHP convention in the ten years or so I’ve worked with the language. It seems more prevalent in C#. The prefix is Hungarian-style notation that came from loosely-typed languages to donate its type. Tools and IDEs have got better so that we no longer need to do that. Hungarian notation was already considered “old hat” when I started PHP.

davestewart's avatar

My background is AS3, so that goes some way to explaining it, whether considered old hat or not :P

Please or to participate in this conversation.