HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

How the Vanilla dev staff decides important issues

Comments

  • TimTim Vanilla Staff

    Vanilla Forums COO [GitHub, Twitter, About.me]

  • DaazKuDaazKu Admin
    edited March 2016

    So many bytes used for nothing...
    So many keystrokes done for nothing...
    That makes me sad :(

  • R_JR_J Admin

    Good to see that you take your time for such important decisions :wink:

  • And a new poetic form, the DaazKu...

  • I agree with the decision.

    The most important thing with coding standards is consistency and clarity.

    grep is your friend.

  • I think the current standards/guidelines should be expanded e.g spacing decision like (· representing spaces)

    if·([condition])·{
    
    }
    
    if·([long condition]
    ····&&·[long condition])·{
    
    }
    

    Do we do?

    namedFunction(·$var1,·'some string');
    
    namedFunction(·$var1,·$var1·);
    
    $namedArray['some string'];
    
    $namedArray[·$var1·];
    
    if·(·$var1·) {
    
    }
    

    like some frameworks

    Or

    namedFunction($var1,·'some string');
    
    namedFunction($var1,·$var1);
    
    $namedArray['some string'];
    
    $namedArray[$var1];
    
    if·($var1) {
    
    }
    

    Like others.

    Both wordpress and phpBB have guidelines to this degree and I have found it has helped quite a bit. I would check out this guideline not to copy exactly, but to give you an idea.

    If I know I can bare than in main and also set up some git filters.

    Even the current standard have cause some confusion or differences, and there is still a legacy from the old style.

    Even the use of strings when it is ok to double quotes or single. Not so much for performance, but consistency and reduce the chance of stupid errors, and germinally be readable.

    grep is your friend.

  • @x00 The latter style - no padding inside brackets & parenthesis. I'm amenable to a doc PR that adds that in a reasonable place if it isn't in there.

    We have no specific guidelines on double vs single quotes currently. Generally, I favor single quotes for short non-language strings (like array keys) and double for longer stuff like UI text. I think Vanilla trends toward this but it's pretty fuzzy, and I'm not sure how to write that as a standard or whether the council must be convened for ratification. :lol:

  • I'm in favour of this style of concatenation

    'some string' . $someVar . 'another string';
    

    not

    'some string'.$someVar.'another string';
    

    any operator too should have space either side.

    grep is your friend.

  • the edit button also make doc PRs easier.

    grep is your friend.

  • I recommend git filters that trim trailing spaces and blank lines.

    grep is your friend.

  • x00x00 MVP
    edited March 2016

    given that language text can have formatString bracket in it like My {Name}. I think language strings should be single not double.

    Also the current locales are single.

    grep is your friend.

  • @x00 said:
    I'm in favour of this style of concatenation

    Unfortunately, we've standardized on the latter (no spaces).

    @x00 said:
    any operator too should have space either side.

    That is correct, and I believe it is in our standard.

  • @Linc said:

    @x00 said:
    I'm in favour of this style of concatenation

    Unfortunately, we've standardized on the latter (no spaces).

    @x00 said:
    any operator too should have space either side.

    That is correct, and I believe it is in our standard.

    Excepting the concatenation operator >:)

    I don't really care, just thought it was a funny juxtaposition.

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • @Linc said:

    @x00 said:
    I'm in favour of this style of concatenation

    Unfortunately, we've standardized on the latter (no spaces).

    :D

    grep is your friend.

  • One of the problem you have is old variable and properties that started with upper-case.

    So we have a situation with two styles side by side.

    Things like ->data() vs ->Data sometimes you do want to access it directly.

    grep is your friend.

  • @x00 said:
    One of the problem you have is old variable and properties that started with upper-case.

    One day we'll do a big backwards compatibility break and go for 3.0. :) Until then, best to leave variable casing alone.

Sign In or Register to comment.