>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618938. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !306 >>> <h3>Problem/Motivation</h3> <p>A Drupal developer opening this module should be able to guess a name before reading it. Most of Yoyaku already reads that way, but an audit of all 1032 PHP files against core's own naming found several groups where the module invents a shape core already has a word for. Every candidate was counted against core itself, over core/lib and core/modules, so each finding is a difference from core rather than a matter of taste. A word core never uses is only a defect where core already has a word for the same thing.</p> <p>Renames are free here: the module is pre-1.0 and reinstall-only, so there are no update hooks and no BC layer to carry.</p> <h3>What the audit found</h3> <ul> <li><strong>11 test traits do not end in <code>Trait</code></strong>: <code>StartsFromAnEmptySite</code>, <code>HoldsWithoutThrottling</code>, <code>RunsEveryScenario</code>, <code>SignsInOnce</code>, <code>RecordsQueryCounts</code>, <code>WaitsForTheNextPage</code>, <code>HoldsOneLine</code>, <code>AllowsForALoadedRunner</code>, <code>KnowsHowThisCoreGroupsAssets</code>, <code>DrawsAHall</code>, <code>FoldsTheMap</code>. In core, 265 of 269 traits end in <code>Trait</code>, and one of the four exceptions is a typo. A sentence-shaped name in a class's <code>use</code> list gives no clue that it is a trait.</li> <li><strong>Words core has its own verb for.</strong> <code>give</code>, <code>giveBackPlace</code>, <code>giveUpFirst</code> and <code>givenPartition</code> against core's zero <code>give</code>-prefixed methods and 8 <code>release</code>-prefixed ones. <code>activePinning</code>, <code>activeConfiguration</code> and <code>activeOrder</code> against core's 16 distinct <code>getActive</code> methods and zero bare <code>active</code>. <code>recomputeState</code> and <code>recomputeOnce</code> against core's 9 <code>compute</code> methods and no <code>recompute</code>.</li> <li><strong>Bare-noun template methods on the overview and order forms.</strong> <code>columns()</code> and <code>cells()</code> do what core calls <code>buildHeader()</code> (35 uses) and <code>buildRow()</code> (37), and <code>SelectableOverviewFormBase</code> already declared a <code>buildRow()</code> beside a bare <code>header()</code>, so this is the module's own precedent as much as core's. The same applies to <code>tabRoute</code>, <code>collectionRoute</code>, <code>emptyText</code>, <code>savedMessage</code>, <code>storage</code>, <code>tableKey</code>, <code>actionOptions</code>, <code>batchTitle</code>, <code>selectionWarning</code>, <code>activeChips</code> and <code>entityTypeId</code>. Core's form template methods are consistently verb-prefixed: <code>getCancelUrl()</code> 52 uses, <code>getQuestion()</code> 50, <code>getConfirmText()</code> 42.</li> <li><strong>The <code>of()</code> readers.</strong> Core has no <code>of</code>-prefixed method anywhere. Four unrelated classes declared <code>of()</code> and three more declared <code>ofSlot()</code>, each meaning something different, so each is renamed for what it returns rather than for its argument.</li> <li><strong>British spelling</strong>, in 408 places: <code>cancelled</code>, <code>cancelling</code>, <code>labelled</code>, <code>centre</code>, <code>colour</code>, <code>signalled</code>, <code>grey</code>, <code>catalogue</code>. <code>ResourceTypeCatalogue</code> was British and also not core's word for "which of these are available here", so it becomes <code>ResourceTypeRepository</code>, which is what core's own jsonapi calls the same job.</li> <li><strong>Hook and subscriber class suffixes.</strong> 371 of the 442 classes in core's <code>Hook</code> directories end in <code>Hooks</code>; 46 of ours did and 7 did not. 106 of the 127 classes in core's <code>EventSubscriber</code> directories end in <code>Subscriber</code>; ten of ours did not.</li> <li><strong>camelCase variables.</strong> 29 parameter names and 57 local names were lowerCamel while the rest of the module already used snake_case, so the module disagreed with itself. Core uses snake_case for both.</li> </ul> <h3>What is deliberately not changed</h3> <p>Recorded here so a later audit does not "fix" them. Each was flagged by a first pass and then cleared by reading what core actually does.</p> <ul> <li><strong>The stored value <code>cancelled</code> stays a stored value.</strong> It is written into booking and transaction rows on a live site, into an <code>order_retention</code> config key, and into the orchestra workflow payloads that route on that literal. So the constant name is now <code>STATE_CANCELED</code> while its value is still the old string. Changing the value is a data migration and a cross-module change, not a rename.</li> <li><strong>kessai's constants keep kessai's spelling</strong>, both <code>PaymentInterface::STATE_CANCELLED</code> and <code>PaymentEvents::CANCELLED</code>.</li> <li><strong>Bare-noun readers on value objects stay.</strong> <code>PolicyContext::lines()</code>, <code>PolicyOutcome::violations()</code>, <code>PolicyScope::host()</code> and <code>TransactionContext::transaction()</code> read oddly, but core does the same in the same kind of class: jsonapi's <code>EntityCondition</code> has <code>field()</code>, <code>operator()</code> and <code>value()</code>, and workflows' <code>State</code> has <code>id()</code>, <code>label()</code> and <code>weight()</code>. On config entities, core's own <code>NodeTypeInterface</code> declares <code>displaySubmitted()</code>, which is the shape of <code>autoConfirms()</code>.</li> <li><strong>Promoted constructor parameters stay lowerCamel</strong>, because they are properties. That distinction is what makes the variable sweep not a blind one.</li> <li><strong>Snake_case properties on config entities stay</strong>, because the property name is the config key, as core's <code>NodeType</code> declares <code>$new_revision</code>.</li> <li><strong>Abstract classes not ending in <code>Base</code> stay.</strong> 31 of the 110 abstract classes in core's lib are named that way, including <code>DraggableListBuilder</code>, which <code>DraggableWeightedListBuilder</code> deliberately mirrors.</li> <li><strong>PascalCase constraint plugin ids stay</strong>, because that is what core uses (<code>AllowedValues</code>, <code>EntityBundleExists</code>), unlike every other plugin type.</li> <li><strong>The service ids stay.</strong> The ones without a module prefix are core's own shapes: <code>logger.channel</code>, <code>cache_context</code> and <code>plugin.manager</code>. Only <code>resource_type_catalogue</code> moved, and only for its spelling.</li> </ul> <p>Also verified clean, with nothing to change: PascalCase type names and file names matching the type they declare; the <code>Interface</code> and <code>Exception</code> suffixes; UPPER_SNAKE constants; route names, permission names, menu, task and action link ids; entity type ids and plugin ids; and test classes ending in <code>Test</code> with no two consecutive capitals in a test method name.</p> <h3>Remaining tasks</h3> <p>Three follow-ups came out of this and are not in the merge request, because each is a coherent group of its own and folding them in would leave a half-done rename visible in the diff.</p> <ul> <li><strong>The <code>for</code> prefix.</strong> 33 declarations across 12 names (<code>forResource</code>, <code>forOrder</code>, <code>forSlot</code> and so on) against exactly one in core, <code>forUpdate()</code>, which is the SQL clause rather than a getter.</li> <li><strong><code>BookingWorkflowStarter</code> is in the wrong directory.</strong> It sits under <code>EventSubscriber</code> but implements <code>WorkflowStarterInterface</code>, not <code>EventSubscriberInterface</code>, so it is a misplaced file rather than a misnamed class, and moving it changes its namespace.</li> <li><strong><code>WaitsForTheNextPageTrait</code> has no users.</strong> It solves a real problem, a stale element reference after a submit, and nothing calls it. It is the tool for the remaining click sites that still go through <code>find(...)-&gt;click()</code>.</li> </ul> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code on the merge request. I reviewed and ran the work myself before posting it.)</p>