-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static Code Analysis with Php Inspections fixes #1377
base: master
Are you sure you want to change the base?
Conversation
…orks faster than invoking functions in PHP.
…rstr(...)/strpos() for better performance because matched patterns does not contain any characters.
…andling logic behind as well. Using array access is a preferred way, because you have to implicitly write (read as document) errors handling code.
…f variable function call. Using variable function instead is a micro-optimization.
…nt do not match the ones in respective function or method declaration.
…. Prefix usage aids in identifying the source of the ID within the code and the more_entropy parameter improves randomness.
* the constructor to pass a built-in array of configuration, without load it from file. | ||
* I.e. Propel\Generator\Config\QuickGeneratorConfig class. | ||
* | ||
* @return null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
void
@@ -25,7 +25,9 @@ class FileLocator extends BaseFileLocator | |||
* By default, the locator looks for configuration file in the current directory (where bin/propel script is running) | |||
* or in a 'conf' or 'config' subdirectory. | |||
* | |||
* @param null array $configDirectories The directories list where to look for configuration file(s) | |||
* @param null $configDirectories |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
null
itself can never be valid. There must always be a 2nd param type.
probably
array|null
* @param null array $configDirectories The directories list where to look for configuration file(s) | ||
* @param null $configDirectories | ||
* | ||
* @internal param array $null $configDirectories The directories list where to look for configuration file(s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can then be removed
@@ -61,6 +61,8 @@ public function __construct(FileLocatorInterface $locator = null) | |||
* Replaces parameter placeholders (%name%) by their values for all parameters. | |||
* | |||
* @param array $configuration The configuration array to resolve | |||
* | |||
* @return array|void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...|void
is not a thing
Use ...|null
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, void
is a thing. It's used when the function does not return anything. So its ok to have it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not together with with another type. That by its very core definition does not exist :)
See http://www.dereuromark.de/2015/10/05/return-null-vs-return-void/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PHP7 has a void return type in its core, so it's semantically helpful to say this function returns an array or simply something insignificant. Array or null is something different and would imply that null is significant where void
says pretty much the opposite - nothing new for you.
Since this function does not actually return anything, void
is perfectly correctly placed here.
A question that can be asked later is why this function returns void but that's out of scope of this PR. This PR is about making the doc and other stuff coherent with coding standard and technically correct annotations. This annotation is correctly placed so should stay that way. Changing that and its code now means changing the purpose of this PR - which should be avoided at all costs, considering the diff is already huge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are wrong about this.
Void means that this method cannot by definition return anything, you "may" not check on the return result, as it makes no sense.
So if something returns anything not null, then it always must always return null then (instead of void) as alternative. Because then you actually do check on the return type and !== null
etc.
As the blog post clearly explains, there is no something|void
from a logical stand point.
PHP7 typehinting you mentions actually backs this up to 100%, but this is already something done for many many years now - on a pure semantic level of course.
PHP7 here is more the result of those many years of semantic only becoming a implemented code piece now. Which is a good thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still disagree on that and what you claim in the blog post. Semantically, you can not just replace void by null just because the function has a state where it can return something not null|void'ish. The interpretation of array|void
is different to array|null
since later would imply null is signification as its an actual type. That is completely independent of the fact that you check the result type.
However, one thing is for sure: Changing that annotation means changing the function behaviour and its interpretation, which is out of scope of this PR. So, technically, its completely fine to place void here, since return;
is void. Whether that makes sense in combination with another return type is a question you can ask later on - although I'd still disagree on your interpretation of what void
means in combination with a real type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imply null is signification as its an actual type
But it IS significant in its type - when checking on the return type there is literal NULL
you will get back. For that code that checks the return type it is of absolute irrelevance how that null came there, all that matters is that there can be one returned then.
You are arguing from exactly the wrong direction.
Return types matter for the code that has to use it, not the actual method. At least for the scope we are discussing right now.
By saying void you say that this method cannot return something, but then you also say array is returned, which contradicts the previous statements. those cannot exist together, as outlined now many times before. If you start returning sth, you can only make it nullable, but never ever void again.
As to this PR and the scope: Of course I agree - as mentioned above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also note that PHPStorm and alike can work with what I recommend, and they outline with yellow misuse of this. As a developer you get earlier feedback about these issues. Let the IDE help you where possible. In recent versions the IDEs understand exactly this and both for the method itself and for the code using it will help to provide exactly what I outlined above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As already said, I disagree on your interpretation on that. Let's move on with the actual purpose of this PR.
@@ -89,6 +95,8 @@ public function postUpdate($builder) | |||
* The actual deletion is made by the query object, so the AR class must tell | |||
* the query class to enable or disable archiveOnDelete. | |||
* | |||
* @param $builder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type missing, also below.
@@ -503,8 +503,10 @@ private function appendIndexNode(Index $index, \DOMNode $parentNode) | |||
/** | |||
* Appends the generated <unique> XML node to its parent node. | |||
* | |||
* @param Unique $unique The Unique model instance | |||
* @param Unique $index |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All object types should be FQCN, but this could be outside of this PR scope, maybe a follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary to have FQCN everywhere. Only when its ambiguous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a common practice for all library and framework code in PHP to have FQCN here always, that will get rid of use statements that are only included to make doc blocks (semantics). Amongst other advantages. There are no disadvantages, there are sniffs to auto-fix this (see spryker one) as well as IDEs like PHPStorm to also do that on its own.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But as I said: Out of scope now of course.
The changes are already getting a bit too much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not common practice. I prefer as many others to have it not unnecessary verbose. So please don't introduce now full class names everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of a PR like this then? And what are the changes of it being accepted?
It also seems to comply with a lot of "best practice" approaches so far established in PHP.
FQCN doc blocks is just one of many.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of a PR like this then? And what are the changes of it being accepted?
See the title "Static Code Analysis with Php Inspections fixes". As far as I saw, all inspections are correct in terms of "we as propel accept on that", but I'm not done looking through all changes yet. However, a inspection that says "FQCN is mandatory for @param and @return" is not something I'd agree.
It also seems to comply with a lot of "best practice" approaches so far established in PHP.
Well, its your opinion that it is best practices - I bet I find enough people that have a different opinion on that. Stating its best practice in "whole PHP" is a very bold assumption I doubt you can prove, so I'd be very careful to play the best practice card. If you can show me a statistics that shows that most libraries use FQDN everywhere then we can talk about that.
Can someone check sqlite errors? |
…ull(...)' calls can be safely replaced with 'null === ...' constructs (or 'null !== ...' if the original construct was negated).
…n applied to a variable sequentially.
@@ -842,7 +842,7 @@ public function __toString() | |||
foreach ($table->getColumns() as $column) { | |||
|
|||
$columns[] = sprintf(" %s %s %s %s %s %s %s", | |||
$column->getName(), | |||
$column->getName(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use it for restart travis checks, it some times get false-positive errors, like that dc24753
Maybe this can be re-done in smaller chunks and then applied piece by piece with easier review. |
No description provided.