[RFC|Accepted] Coding Guideline Modifications
Re: [RFC|Accepted] Coding Guideline Modifications
Another issue: are new functions required to not use globals and instead have them dependency injected?
Re: [RFC|Accepted] Coding Guideline Modifications
I don't think we should be so strict about commit messages. It really slows down development. Having meaningful messages is important, but things like capitalization, spelling and too long lines really shouldn't require rebases every time.
- nickvergessen
- Former Team Member
- Posts: 733
- Joined: Sun Oct 07, 2007 11:54 am
- Location: Stuttgart, Germany
- Contact:
Re: [RFC|Accepted] Coding Guideline Modifications
I don't really like this one. We have globals everywhere in the code base. And I prefer it much more than having 6+ additional parameters on a function.Oleg wrote:Another issue: are new functions required to not use globals and instead have them dependency injected?
Member of the Development-Team — No Support via PM
- imkingdavid
- Registered User
- Posts: 1050
- Joined: Thu Jul 30, 2009 12:06 pm
Re: [RFC|Accepted] Coding Guideline Modifications
+1nickvergessen wrote:I don't really like this one. We have globals everywhere in the code base. And I prefer it much more than having 6+ additional parameters on a function.Oleg wrote:Another issue: are new functions required to not use globals and instead have them dependency injected?
- bantu
- 3.0 Release Manager
- Posts: 557
- Joined: Thu Sep 07, 2006 11:22 am
- Location: Karlsruhe, Germany
- Contact:
Re: [RFC|Accepted] Coding Guideline Modifications
Your statement is missing a reason.nickvergessen wrote:I don't really like this one. We have globals everywhere in the code base. And I prefer it much more than having 6+ additional parameters on a function.Oleg wrote:Another issue: are new functions required to not use globals and instead have them dependency injected?
Re: [RFC|Accepted] Coding Guideline Modifications
If people write correct commit messages most of the time and occasionally make a mistake, it's no big deal to fix them. In projects that do not have commit message requirements I think you end up with a bit of a free for all as people spend that much less effort on commit messages.igorw wrote:I don't think we should be so strict about commit messages. It really slows down development. Having meaningful messages is important, but things like capitalization, spelling and too long lines really shouldn't require rebases every time.
You don't actually have to even go that far for proof, take a look at our own commit messages pre-git.
Where I agree this is a big issue is in contributors' commit messages. And the real problem I would say is that the developers can't fix contributors' commits in github pull requests.
Re: [RFC|Accepted] Coding Guideline Modifications
There is a difference between having formal requirements for commit messages, which we have and enforcing a particular capitalisation in commit messages. Let's just move on.
- bantu
- 3.0 Release Manager
- Posts: 557
- Joined: Thu Sep 07, 2006 11:22 am
- Location: Karlsruhe, Germany
- Contact:
Re: [RFC|Accepted] Coding Guideline Modifications
This has been changed now. See viewtopic.php?f=99&t=42353igorw wrote:The file header still needs to be adjusted. Currently it is:I'd suggest something among the lines of:Code: Select all
/** * * @package {PACKAGENAME} * @version $Id: $ * @copyright (c) 2007 phpBB Group * @license http://opensource.org/licenses/gpl-license.php GNU Public License * */
This should only apply to files new to the develop (ascraeus) branch.Code: Select all
/** * * @package {PACKAGENAME} * @copyright (c) 2010 phpBB Group * @license http://opensource.org/licenses/gpl-2.0.php GNU General Public License, version 2 * */
Re: [RFC|Accepted] Coding Guideline Modifications
hi,
Is there a phpbb specific guideline on using docblocks or does this one apply ?
http://manual.phpdoc.org/HTMLSmartyConv ... s.docblock
Is there a phpbb specific guideline on using docblocks or does this one apply ?
http://manual.phpdoc.org/HTMLSmartyConv ... s.docblock
Re: [RFC|Accepted] Coding Guideline Modifications
Those are the rules for formatting them, yes.
We have a few more phpBB specific rules: Always document function return value using @return null if no value is returned. Always document all parameters with type and description. But I think that's all. Oh and we don't always document member variables, but often that is rather helpful (no need for @access though since we use PHP5 and require use of access modifiers anyway).
We have a few more phpBB specific rules: Always document function return value using @return null if no value is returned. Always document all parameters with type and description. But I think that's all. Oh and we don't always document member variables, but often that is rather helpful (no need for @access though since we use PHP5 and require use of access modifiers anyway).