-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
configuration getters - method name and intent consistency #935
Comments
For a method that returns a non boolean value, the method name should start with "get". For method that returns a boolean value, the general convention is to name the method as if a question is asked. For example, "discountTax" can be interpreted as "shall we discount tax?". However, people ask questions in many ways and that's where the inconsistencies come in. The same question can be asked as "is tax discounted?" which would translated to method name "isTaxDiscounted". In this particular case, I think "isTaxDiscounted" and "isTaxAppliedOnCustomPrice" are better method names. There are thousands of methods that return boolean value in Magento, it would be a big undertaking to review all of them. We may adopt a consistent naming convention and gradually refactor existing non-compliant methods. |
I think it would be valuable to have a standard naming convention for methods returning booleans in place. |
We should review implications with web service deserialization code as well for data entity interfaces. This may be more than just a coding convention - it may be baked into some areas of the code. |
@tang-yu thanks for the extra details. I am hoping that a standard can be agreed upon on soon (using
|
@fooman for Magento2 we are claiming our coding standard to be PSR-1, PSR-2. So best practice, yes but enforcing as a standard probably not. In fact internally we have a statement We'll open a ticket to look at these changes to honor our own best practices. PRs welcomed too. |
@fooman Thank you for the suggestion. Please refer to the Community Forums or the Magento Stack Exchange site for advice or general discussion about this issue. The GitHub issue tracker is intended for Magento Core technical issues only. |
- Merge Pull Request magento-engcom/magento2ce#935 from RomaKis/magento2:12482 - Merged commits: 1. 8e426fe
[EngCom] Public Pull Requests - 2.2-develop - MAGETWO-85311: Added namespace to product videos fotorama events #12469 #991 - MAGETWO-85300: 8437: Silent error when an email template is not found #970 - MAGETWO-85293: 12613: Verbiage Update Required: Product Image Watermark size Validation Message. #985 - MAGETWO-85286: 8176: LinkManagement::getChildren() does not include product visibility. #986 - MAGETWO-85285: 12482: Sitemap image links in MultiStore #935 - MAGETWO-84955: Set Current Store from Store Code if isUseStoreInUrl #12529 - MAGETWO-84764: NewRelic: Disables Module Deployments, Creates new Deploy Marker Command #12477 - MAGETWO-84439: 12180 Remove unnecessary use operator for Context, causes 503 error i… #12220
…rAddress #935 - Merge Pull Request magento/graphql-ce#935 from kisroman/graphql-ce:graphQl-907 - Merged commits: 1. 3e03eec
This reopens #443
Throughout the code base there are a few different approaches to naming methods when retrieving a configuration setting. From
app/code/Magento/Tax/Helper/Data.php
Some other examples:
app/code/Magento/Backend/Block/Page/System/Config/Robots/Reset.php
app/code/Magento/Backend/Block/Page/Notices.php
app/code/Magento/CatalogInventory/Model/Resource/Indexer/Stock/DefaultStock.php
It will be a lot easier to work with Magento if one approach is chosen and consistently used.
The text was updated successfully, but these errors were encountered: