Please remove this requirement: 'WARNING | Interface names should always have the suffix "Interface"'

From Drupal coding standards: Object-oriented code:

6. Class names should not have "Class" in the name.

And with very good reason, because including the word Class any time or every time it is redundant in the element name. The IDE knows it's a class, PHP knows it's a class, and if you are using graphical UML it certainly knows it's a class. But:

7. Interfaces should always have the suffix "Interface".

It's not only inconvenient (verbose, not promptable), it's redundant. Or dare I say "Classist" (pun intended) to the extent that one is treating an Interface as somehow not the same as a Class. In fact, if the system is well designed from an OO perspective, most private variable of clients classes and the parameters of most methods will be typed by Interfaces, not Classes, so there is in fact even less need to distinguish them (by which I mean, the client class should not have to worry about the naming).

@yukare wrote:

I think that while this is in coding standards we must keep it here.

Well luckily it is only a WARNING.

Maybe you are correct in changing it ..

I am definitely right in changing it, it has a number of disadvantages and no advantages at all (other than painful verbosity).

.. but it must be coding standards and here only after this.

Not sure what you mean by 'must be in coding standards', it is indeed currently in the coding standards (which as I remarked elsewhere, are not written in stone).

I will:

1. Continue debate about it at under the Object-oriented code standards guide.

2. Continue to use an 'I' prefix for interfaces (not 'Interface' suffix) and hope that my projects are not prevented from moving from the sandbox. Coding standards have a purpose, but they should be capable of evolution, should not "bully" or "boss" experienced developers around.

In the meantime, please do not simply close this issue, and thanks for your feedback and interest.

> you should open a Drupal core issue to discuss this and tag it with "coding standards".

Thanks, done.

@t0xicCode wrote:

I took a look at a few of the projects in PHP-FIG, and it seems that those that specify rules for interface names follow the example of Symfony 2 (which we are already using)

Thanks for your enquiry. To be clear, I do not wish to prevent others from using the Interface suffix (although I don't like it all, and would not encourage anybody to use it), I just want the coding standards and Coder to also permit other conventions (like the popular 'I' prefix convention) that do not suffer from these problems:

- Excessively verbose so requires a lot more typing.

- Excessively verbose, so wastes a huge amount of diagramming real estate and causes clutter in Unified Modeling Language (UML) diagrams where the fact that something is an interface is already made clear through the UML Interface symbol(s). Imagine for example some of these UML diagrams with Interface suffixes everywhere.

[EDIT: see also now diagrams added to Drupal.org at comment #13 below.]

- One can't prompt easily in IDEs or UML tools to find all interfaces, since using a suffix, not a prefix. This is particularly important when employing the crucial "design by interface-as-contract" principle, because say in a UML tool one can - if using say the 'I' prefix convention- ensure easily that one is working with interface types as injected parameters of client classes.

If Symfony uses the Interface suffix, I would hazard an educated guess that they are not also doing their software engineering with much, if any, graphical UML support, because it is simply not UML-friendly.

@mparker17 I appreciate the time you've taken to investigate these at #8.

Some provocations to anybody _insisting_ on adorning every interface with the Interface suffix.

Q1: Why don't you already know it's an interface ? (Doesn't your IDE or even your UML tool make it clear already ?)

Q2: How are you finding your interfaces in your IDE or UML tool ? Are your prepared to race against me prompting on an 'I' prefix ?

Q3: The big one. Why don't you also include a Class suffix (specifically against the Drupal coding standards) in every class ? I mean after all, if you are supposed to be designing against an interface-as-contract, then you might have more than one implementation class, and one could argue you should make it clear these are classes not interfaces by sticking the word Class in every time !

The 'I' prefix convention does distinguish interfaces from classes, however it does it in an easily promptable and "iconic" way; the 'I' prefix acts much like a small symbol that indicates whether something is an interface. Indeed, in Eclipse it uses a small '(I)' in a circle as icon (I am otherwise mostly a NetBeans IDE fan).

Some UML diagram examples that show why the Interface suffix pollutes UML diagrams without adding any value

The following diagrams show some work in progress, the designs are not stable yet, however they make the point well enough. In UML2 Interfaces are represented by a circle icon, and when the Interface is shown without an attributes or operations compartment, it is shown as a small circle, sometimes also called "lollipop" notation, or "ball and socket" notation if combined with the Usage relationship notation.

None of these would benefit from having an Interface suffix everywhere, in fact it would look ridiculously redundant and bloated (whereas the subtle 'I' prefix is ok):

Please note that just because an Interface in a UML diagram shows an empty attributes compartment (and thus displays as a rectangle) does not mean it does not have any operations ! It might just mean that it has operations in the model that are not visible because the operations compartment is not shown. This is a popular diagramming device in some UML tools (above is MagicDraw UML) to force the Interface to show as a rectangle so that connections can be made more easily.

@mparker17 wrote:

it would be worth examining what other frameworks currently do before changing the Drupal coding standards

It is also be worth looking at what top OO people beyond PHP, including Java people, who have used graphical UML-driven software engineering for well over a decade, do. In fact I have already had a good look, indeed a really really good look, daily, for years, as it's "m' main thang", and as soon as you do a lot of graphical UML you discover that sticking the word 'Interface' on the end of every interface is just plain horrible.

An IDE example showing why the 'I' prefix convention is better than the 'Interface' suffix convention

Here just in NetBeans IDE, prompting on methods in an object-oriented encapsulation of the Drupal7 menu system:

Note how the 'I' prefix makes things clearer on prompting on operations, and takes up less space.

Another provocation to any Interface suffix advocates

Q: Are you also including 'Interface' in every local or class variable name ?

When doing design-by-interface-contract, one in fact only needs to bring attention to when the variable is NOT targetting an interface (such as when an explicit class is chosen and created via 'new AnImplementation(..)' rather than fetching an interface product via a factory).

Raised to critical, before the 'Interface' suffix convention (instead of the demonstrably handier and more concise 'I' prefix convention, or even the no-prefix-or-suffix convention) becomes part of Drupal Religion Dogma on the Drupal8 Island, noting that Drupal8 is upon us and I am clearly the person who is going to model it in graphical UML more than anybody else. Which means "listen to me", not just to people who are new to OOP.

@drunken money

I am not "fanatical" about UML, I am a staunch advocate of it and proponent of it (and I teach it and promote it) because I have experienced the enormous benefit of it. I have also observed the problems that arise with projects like Drupal that have so far chosen not to leverage such information technologies that are well used on other software engineering projects, and that I sorely miss when working with Drupal (although I do appreciate what one can do with it as a CMS).

I look forward to seeing how - as Drupal increasingly adopts object-orientation (and hopefully more OO Design Patterns) - the community is going to manage without more graphical software engineering, because graphical UML is, quite simply, the language of OOP and Design Patterns. It is used in nearly every single IT book involving object-orientation from the last 2 decades.

Are you going to invent your own graphical software engineering language to be used only on the Drupal Island ?

Besides it's not just about UML

There are number of reasons for not adopting the Interface suffix convention that have nothing at all to do with UML, and I have already listed some of them above (such as the fact that for example the I prefix approach enables IDE prompting, and the fact that design-by-contract does not require "Interface" to be shouted from the roof every time, because people who are used it know that they should be injecting Interface types as method arguments).

BTW I hope you are adding the word Class as suffix to every class, in case your IDE does not already know it, to at least be consistent with the Interface suffix approach; or is an Interface something magical or highly unusual in your world ?

Here's a good interface:

Animal

Here's another:

IFly

ISwim

A useful resolution to this matter, as I have suggested multiple times elsewhere, is to have different Coder compliance modes, including one for a UML-friendlier PHP coding mode. I am not forcing other people to use my approach; I just don't want to be told by Coder all that time that my approach is not valid (does not "pass") in this case, and in a couple of other cases.

If you want to do diagrams and the suffixes are such a large problem, why not just run a local regexp to change the Drupal convention to yours before creating the diagrams?

Congratulations on cleary completely misunderstanding (or maybe not knowing at all) how it is that UML is used progressively, iteratively, in software engineering projects that support full round-trip model-driven engineering with graphical support, or even UML used just for reverse engineering as I have demonstrated it for PHP and for Drupal. Is this suggestion of yours serious. Do you actually expect me to take anything you have to say about it serious after making such as suggestion ?

I have nothing further to add to the matter, only to say that I will not under any circumstances adopt the Interface suffix convention, and I don't care what other Drupalers think about that stance, nor do I care whether my projects make it out of the sandbox because it does not pass Drupal coding conventions I choose not to use.

I will make my OO tutorial modules for Drupal that demonstrate a UML-friendlier coding style for Drupal available to the world either through your sandbox or my own Drupal sites, for those who care. And I am also modelling Drupal8 in graphical UML/SysML using component-based systems engineering strategies as well. For those who care.

For those who don't care; follow "drunken monkey" on the Drupal Island and, ahem, run your code through a local regexp AFTER coding against a Drupal convention and then do your UML diagrams ...

[2015-05-30 EDIT: To clarify why the 'regexp' substitution suggestion is completely ridiculous. I can see (at least) 3 ways of using this to replace every Interface suffix with nothing in a project and none of them achieve what I have described here, not least because "drunken monkey" seems hung-up on the UML-friendly aspect and is not acknowledging the advantages of having an 'I' prefix or no prefix at all both from a design-against-contract and PHP IDE tool perspective:

1. Replace every occurrence of Interface in the live PHP code (in your Git project). Then transform it to XMI (using PEAR:PHP_UML) then to UML diagrams. Well done. You have just created Git hell. And you have no advantage in your IDE regarding prompting on an 'I' prefix. And you will by typing the 9-characters Interface over and over and over in your original code without any benefit at all (until you destroy it with regexp replacement of course).

2. Copy every bit of PHP code to another parallel PHP code set with regexp replacement of every occurrence of 'Interface' as a suffix, then transform that 2nd PHP set to XMI (using PEAR:PHP_UML). Once again, you have no advantage in your IDE regarding prompting on an 'I' prefix, and you will still be typing Interface over and over and over in your original code.

3. Peform regexp replacement of every occurrence of 'Interface' as a suffix in the XMI file (every time you generate it from the PHP that has Interface suffixes all through it) and then enjoy diagramming without the suffix Interface emblazoned across every UML Interface symbol that has a nice interface indicator anyway. And once again, you have no advantage in your PHP IDE regarding prompting on an 'I' prefix, and you will still be typing Interface over and over and over in your original code.

And every single one of these wise ideas completely undermines any opportunity of having graphical UML modelling fully integrated with your IDE for PHP-driven Drupal, which capability many Java, C++, C# and .NET developers enjoy, and which technology could, and I hope will, become available for PHP-driven Drupal.

What a super practical suggestion, clearly 'drunken monkey' is a very experienced expert in model-driven development with UML and perhaps even an expert in design-by-contract (you know, that famous OO approach where you know already that you are always coding against an interface).

Or, the Drupal Coding Standards team could just instead relax this convention and permit either no prefix or suffix, or a promptable 'I' prefix, with an alternative Coder compliance mode]

I wrote:

> I have nothing further to add to the matter ..

Indeed I do, without a single bit of UML in sight.

BlahInterface method(thingInterface ThingInterface, thisInterface ThisInterface) ThatInterface, AnotherInterface,

keep typing, it's only 9 characters each time, Interface, Interface feels good, Interface, FatInterface, ThinInterface, SillyInterface, Interface,

anotherMethodWithArgs(anotherInterface AnotherInterface, anInterface AnInterface) just in case once more Interface, or again, Interface.

Interface
Interface
Interface
Interface
Interface
Interface