-
Notifications
You must be signed in to change notification settings - Fork 0
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
Epo 7766 #24
Epo 7766 #24
Conversation
As per Andrew of NY Studio's suggestions EPO-7766
EPO-7766
I did not refactor much of the Asset and Element service classes, as they likely will be going away, nor did I refactor out much of the logic from the controller as it will likely change quite a bit. |
EPO-7766
Also checking in PhpStorm prefs EPO-7766
EPO-7766
EPO-7766
I also didn't both to change the name of the custom table from "universal*" to "canto*" since this table will be going away. |
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.
Usually I add this to my project or system-wide .gitignore
:
.idea
...unless you really want the PhpStorm meta attributes checked into your project.
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.
That makes sense
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.
For inherited methods, typically the block comment should just be:
/**
* @inheritdoc
*/
Which tells the IDE/documentation parser to use the docs from the parent method
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.
Is there a way to automatically tell PhpStorm to do this?
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.
In general, you may find your code is more easily digestible if you use the "happy path" methodology:
https://lamp-dev.com/a-quick-guide-to-psr-coding-style-recommendations/1887#happy-path
Also sometimes called "early return", the idea is to reduce cognitive load by having your methods return early for exceptional conditions.
Similar to the section below this at the same URL in terms of avoiding if/else
Probably not worth a refactor for working code, just noting it.
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.
This is an interesting comment to me - when working primarily with Java in a large enterprise environment we were always told to never "short circuit" a method/function and to only ever have a single return
statement. Perhaps that's because of the monolithic methods/functions that exist in enterprise codebases?
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.
Overall looks good, as you said, mostly PhpStorm doing it's thing. I probably should have mentioned this ahead of time, but PhpStorm does help you automate moving namespaces:
https://www.jetbrains.com/help/phpstorm/move-refactorings.html#moving-php-namespace
Probably I can show you a few other tips to make using PhpStorm more efficient for you, but it looks like it's helping to clean things up already!
EPO-7766
…integrator into EPO-7766
No description provided.