phpBB

Development Discussion Board

phpBB's testing ground of bleeding edge code
Advanced search

[RFC|Accepted] Coding Guideline Modifications

These requests for comments have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.

Re: [RFC|Accepted] Coding Guideline Modifications

Postby callumacrae » Thu Sep 15, 2011 7:54 am

Well yeah, they're parentheses to mark an object, not a block of code. Objects always want the parentheses on the same line, as this wouldn't make sense:

Code: Select all
fn(
{
    a: 'foo',
    b:
    {
        c: 'bar'
    }
})
"In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders"
—Douglas Crockford

View my MOD, phpBB Mobile
User avatar
callumacrae
Website Team
Website Team
 
Posts: 881
Joined: Tue Apr 27, 2010 9:37 am
Location: England

Re: [RFC|Accepted] Coding Guideline Modifications

Postby wGEric » Thu Sep 15, 2011 6:17 pm

callumacrae wrote:Well yeah, they're parentheses to mark an object, not a block of code. Objects always want the parentheses on the same line, as this wouldn't make sense:

Code: Select all
fn(
{
    a: 'foo',
    b:
    {
        c: 'bar'
    }
})

Objects don't always want the curly brackets on the same line. Your code is valid and you will get the result that you expect. Are you proposing to put the curly bracket on the same line for objects?

Here is some test code:
Code: Select all
<script>
var test =
   {
      a: 'foo',
      b:
      {
         c: 'bar'
      }
   };
   
console.log(test);

var fn = function() {
   return
   {
      a: 'foo'
   }
};

console.log(fn()); // undefined
</script>
Eric
wGEric
Registered User
 
Posts: 506
Joined: Wed Jun 11, 2003 2:07 am

Re: [RFC|Accepted] Coding Guideline Modifications

Postby callumacrae » Thu Sep 15, 2011 7:58 pm

Definitely, or it looks stupid.
"In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders"
—Douglas Crockford

View my MOD, phpBB Mobile
User avatar
callumacrae
Website Team
Website Team
 
Posts: 881
Joined: Tue Apr 27, 2010 9:37 am
Location: England

Re: [RFC|Accepted] Coding Guideline Modifications

Postby Oleg » Sun Nov 27, 2011 10:00 am

Having read some diffs recently I am now firmly in the camp of always specifying @return. Without @return I am never sure if the function returns nothing or the return value is undocumented, and I end up scouring the code to find out, which defeats the purpose of having documentation.
Oleg
3.1 Release Manager
3.1 Release Manager
 
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am

Re: [RFC|Accepted] Coding Guideline Modifications

Postby Oleg » Thu Dec 15, 2011 2:02 pm

How about requiring all sentences in commit messages to begin with a capital letter (unless the first word is a variable or otherwise something that normally begins with lowercase)?
Oleg
3.1 Release Manager
3.1 Release Manager
 
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am

Re: [RFC|Accepted] Coding Guideline Modifications

Postby A_Jelly_Doughnut » Thu Dec 15, 2011 2:32 pm

Seems a little pedantic to me?
A_Jelly_Doughnut
User avatar
A_Jelly_Doughnut
MOD Team
MOD Team
 
Posts: 1751
Joined: Wed Jun 04, 2003 4:23 pm

Re: [RFC|Accepted] Coding Guideline Modifications

Postby naderman » Thu Dec 15, 2011 3:31 pm

Indeed, I think it's common sense to use proper capitalisation, and if there's an occasional exception that's ok, too.
www.naderman.de
Move your forum to Forumatic - we'll take care of maintenance & spam
User avatar
naderman
Development Team Leader
Development Team Leader
 
Posts: 1649
Joined: Sun Jan 11, 2004 2:11 am
Location: Karlsruhe, Germany

Re: [RFC|Accepted] Coding Guideline Modifications

Postby callumacrae » Thu Dec 15, 2011 3:39 pm

Oleg wrote:How about requiring all sentences in commit messages to begin with a capital letter (unless the first word is a variable or otherwise something that normally begins with lowercase)?

I've always worked with first letter capital and ending with a full stop wherever possible.
"In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders"
—Douglas Crockford

View my MOD, phpBB Mobile
User avatar
callumacrae
Website Team
Website Team
 
Posts: 881
Joined: Tue Apr 27, 2010 9:37 am
Location: England

Re: [RFC|Accepted] Coding Guideline Modifications

Postby imkingdavid » Thu Dec 15, 2011 3:51 pm

callumacrae wrote:
Oleg wrote:How about requiring all sentences in commit messages to begin with a capital letter (unless the first word is a variable or otherwise something that normally begins with lowercase)?

I've always worked with first letter capital and ending with a full stop wherever possible.

I suppose that requiring proper English grammar is a good idea for uniformity, although sometimes I have used a lowercase letter in the summary (e.g. [branch] fixed X error in Y.php) since that didn't look too bad. The purpose of the hard stop and capital letter is to indicate the end of one sentence and the beginning of another. However, in a summary like the one able, neither is needed, imo, since there is only the one sentence.
I do custom MODs. PM for a quote!
View My: MODs | Portfolio
Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.
User avatar
imkingdavid
Development Team
Development Team
 
Posts: 900
Joined: Thu Jul 30, 2009 12:06 pm

Re: [RFC|Accepted] Coding Guideline Modifications

Postby Oleg » Thu Dec 22, 2011 6:23 am

I don't care for capitalization that strongly. I do however think that we should document that we don't require any particular capitalization if this is what is decided, or possibly that we suggest proper capitalization but do not require it.
Oleg
3.1 Release Manager
3.1 Release Manager
 
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am

Previous Next

Return to [3.1/Ascraeus] Merged RFCs

Who is online

Users browsing this forum: No registered users and 8 guests