-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Update best_practices.rst #9041
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
Conversation
@@ -26,7 +26,7 @@ A namespace becomes a bundle as soon as you add a bundle class to it. The | |||
bundle class name must follow these simple rules: | |||
|
|||
* Use only alphanumeric characters and underscores; | |||
* Use a CamelCased name; |
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.
We always use "CamelCase", "snake_case", etc. in the docs. Do you find this hard to understand? (I'm trying to better understand the reason for this change). Thanks!
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.
@javiereguiluz In PHP context camelCase
usually uses to describe rule, when first letter is lower-case. If first letter is capitalized, this style usually calls StudlyCaps
.
Reference: http://www.php-fig.org/psr/psr-1/
- Class names MUST be declared in
StudlyCaps
.
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 PSR is an official doc for PHP code style, better use PSR terminology for PHP projects
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.
@SergeyPodgornyy thanks for the info. You are right and using the same terminology than PSR is the right thing to do. I added a minor clarification because StudlyCaps is less known than camelCase. Cheers!
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.
@javiereguiluz Ok, but why you closed this PR without merging? 😒
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.
Ah sorry for not explaining. You sent your pull request to 4.0 branch, but I merged it on 2.7 (this is the commit --> ac99784). You can see your work merged here: https://github.com/symfony/symfony-docs/commits/2.7
Problem is that when I merge in a different branch, the tool we use to merge makes GitHub think that this is closed instead of merged ... but it's merged 😅
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.
Ok, thanks for explanation. But it's merged only for old version? =(
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 changes are "merged up" in all branches, so you can see the change from 2.7 (https://symfony.com/doc/2.7/bundles/best_practices.html) to 4.1 (https://symfony.com/doc/master/bundles/best_practices.html)
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.
@javiereguiluz Oh, thank you. Just the last question. If I'll make a new Pull Request next time, to which branch should I create pull request?
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.
@SergeyPodgornyy We always merge PRs in the oldest maintained branch that is affected by a change. Currently, maintained Symfony versions are 2.7, 2.8, 3.3, 3.4, 4.0 and 4.1 (aka master
).
No description provided.