Proposal: Establish a naming convention (and/or enforce one, but that probably won't be so popular...) so that all form definition functions in core are whatever_form(). This would make all validate/submit functions are whatever_form_validate/submit() and all form theme functions theme_whatever_form().

Pros:
a) Makes it easy to tell at a glance what functions are related to forms and belong together.
b) No more searching API functions and coming across something like system_modules() and thinking it does something entirely different from what it actually does.
c) Consistency!

Cons:
Absolutely none! ;) Unless someone has any objections. :)

Comments

sun’s picture

Issue tags: +DrupalWTF

.

Damien Tournoud’s picture

+1

(I always wanted to do that one day)

sun’s picture

Issue tags: +API clean-up

Tagging for feature freeze.

sun’s picture

@webchick: Is this too API-changish or can we still quickly squeeze this in?

webchick’s picture

Version: 7.x-dev » 8.x-dev

Nope.

mbrett5062’s picture

I am wondering if a naming convention for all functions would not be more useful. I.E. extend this to everything Drupal.
Why just Forms, why not Files and Fields, and everything.

I see all over different naming conventions.

I would propose that we follow the same structure throughout.

whatever_thing_function

more concisely (In what context are we working)_(what are we working on)_(what do we want to do with it)

ie

file_extensions_validate ------ (currently = file_validate_extensions) -1
file_data_save ------------------- (currently = file_save_data) -1
file_content_headers_get ---- (currently = file_get_content_headers) -1
file_usage_delete --------------- (currently = file_usage_delete) +1
node_type_save ----------------- (currently = node_type_save) +1
node_body_field_add ---------- (currently = node_add_body_field) -1
node_content_build ------------ (currently = node_build_content) -1
node_search_admin ----------- (currently = node_search_admin) +1
drupal_form_submit ----------- (currently = drupal_form_submit) +1
form_cache_set ----------------- (currently = form_set_cache) -1
drupal_form_process ---------- (currently = drupal_process_form) -1
drupal_form_validate --------- (currently = drupal_validate_form) -1
form_select_process ---------- (currently = form_process_select) -1

As you can see from the very few examples, we have no consistency anywhere, -1 being different to how I feel it should be done.

Of course this is just my opinion, how this would be ordered is for the team to decide, but consistency is key I believe.

Hope this is of some use to someone who would like to champion this. @webchick :)

TravisCarden’s picture

Issue summary: View changes
Status: Active » Fixed

This problem behind this issue has been solved now that forms are defined as classes. (Yay OOP!)

sun’s picture

Title: Establish naming convention for form definition functions » Establish naming convention for form IDs
Status: Fixed » Active
Issue tags: +DX (Developer Experience)

I don't think that is true. Some form constructors were moved into classes, but their form IDs did not change.

In fact, inconsistent and weirdly named form IDs are even more confusing now that the form ID is buried somewhere in a method of a class, whereas the containing class has a different name. → We have a new discovery DX problem in addition to inconsistent form IDs now.

I don't know what we can do about this, but discovering the form ID (and code) of a form to integrate with or alter requires you to grep the code base now, in order to find the containing class, and in order to find the internal form ID.

Any ideas anyone?

webchick’s picture

Ever since #2109035: Make access checkers (much) easier to find went in, I've been wondering if we could use something similar for form IDs, too. However, Crell didn't approve, I think because it would couple form IDs to a route definition. Though I suppose the method would still exist for those forms that weren't defined by routes (search form block, for example).

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.