Active
Project:
Coding Standards
Component:
Coding Standards
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
11 Oct 2017 at 09:56 UTC
Updated:
10 Jan 2023 at 10:51 UTC
Jump to comment: Most recent
It is sometimes necessary to have empty methods and functions. For example in the Containter class:
/**
* Ensure that cloning doesn't work.
*/
private function __clone()
{
}
Or for a procedural function (this only should happen in unit tests):
if (!function_exists('drupal_set_message')) {
function drupal_set_message() {}
}
At the moment Coder allows say that an empty method in class should be formatted like:
private function __clone() {}
or
private function __clone() {
}
private function __clone() {
}
if (!function_exists('drupal_set_message')) {
function drupal_set_message() {
}
}
Determine a consistent coding standard for empty functions.
Regardless of whether we are dealing with a class, trait or function if empty the declaration should appear like:
private function __clone() {
}
This is because if any functionality is added later to method or function in the diff you will see only additions which is exactly what has occurred. If we allow private function __clone() {} the diff will contain unnecessary change.
Comments
Comment #2
alexpottComment #3
andypostIMO better to have inline comment inside empty body explaining why this function is no-op
Comment #4
alexpott@andypost sure a comment is good but I really don't think that we should mandate that in a coding standard. As the clone example in the issue summary shows the function or method doc block can take care of that. And a comment in the test code is OTT too.
Comment #5
mfernea commentedI just want to mention that currently Coder allows both styles for classes:
and
but only the second one for traits or procedural code.
I would go for the second one in all cases.
Comment #6
alexpottUpdated IS to reflect @mfernea's comment in #5
Comment #7
drunken monkey+1, let's have a consistent standard for this.
I don't really care which of the two it is, though. I think it looks cleaner without a newline, and it's more obvious that the body is empty; but the diff reasoning also makes sense, and has the advantage of not being purely a matter of personal taste. So, I guess, let's go with that.
Comment #8
borisson_I agree with everything in #7, slight preference for the version without the newline.
Comment #9
zaporylieI'm leaning towards version without newline.
Comment #10
effulgentsia commentedWe quickly looked at this during our Coding Standards call today, but given that people commenting so far seem split on whether they like the newline or not, we think this needs more people advocating for it before we try to move it forward in the process.
Comment #11
megachriz+1
I too prefer the version without the newline. But I'm not strongly against the version with the newline.
Comment #12
gappleRelated but slightly different - empty
catchblocks to ignore an exceptionIt looks like there are currently instances in core where a comment is placed above the block, with only a newline inside
and instances where the comment is inside the block
(Most comments look like they provide at least some context, but at least one is just "Nothing to do.")
Comment #13
pfrenssenThis is more relevant nowadays with PHP 8 constructor property promotion that will result in many empty constructors, for example:
My personal preference is also to the version without newline.