WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: coding style Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 5:58 pm on November 13, 2013 Permalink
    Tags: coding style   

    Proposed coding standards change (always require braces) 

    Our current PHP coding standards specify that for if statements, “single line blocks can omit braces for brevity.” All other constructs “should always contain braces as this enhances readability, and allows for fewer line edits for debugging or additional functionality later.” I’d like to propose we always require braces for all blocks.

    One could argue about coding standards all day (not in this comments thread), but allowing braces to be omitted is probably the only thing in our standards that can cause legitimate problems, like making it easier to introduce errors. It also makes code more annoying to patch and less maintainable, and requires larger diffs. And, it’s more work to debug code, as you have to add braces to add debugging lines, then remove them when done. It’s easy to attempt to add a new line inside the conditional and screw it up, which has occurred even a few times in the last few weeks. For example:

    if ( some_conditional() )
        some_new_line();
        return some_function();
    

    Another catalyst here is our new JavaScript standards. Due to multi-line chaining and other situations, it is basically insane to omit curly braces in JavaScript. It would be nice if our standards matched, making this the right time to raise the issue for PHP. Our coding standards have a general emphasis on whitespace and readability, and the lack of braces do generally make code feel lighter and easier to scan, but I think we’ve reached a breaking point. I’ve surveyed the other lead developers and the consensus was that while omitting braces is elegant, it doesn’t best serve the needs of the project (with many people editing many things often).

    I’d like to discuss this during today’s meeting, and ideally make a decision.

    I will mention that adopting this will mean all new code will receive braces. We can discuss what to do with existing code. Please don’t waste any time on a patch to add braces manually; we’d script it and do it in one commit if that’s the route we decide to take. (There’s more than 8,000 structures lacking braces.) Also worth reading in preparation for a discussion is a section in Linux’s contributor documentation on coding style pitfalls, something I’ve linked to before.

    P.S. This wouldn’t change bracing placement. It’s still like this:

    function func_name() {
        if ( some_conditional() ) {
            echo "Braces shall be 'cuddled,' not pushed to the next line."
        } else {
            echo "For all control structures.";
        }
    }
    

    Update: This proposal was accepted during the Wednesday meeting. I’ve updated the coding standards handbook page. We’ve yet to discuss what we’ll do for old code, but all new and changed code should receive braces.

     
    • Bryan Petty 6:09 pm on November 13, 2013 Permalink

      Just thought I’d point out that this would make our control structure guidelines PSR-2 compatible, not that it should be a deciding factor, but it certainly doesn’t hurt.

      • Ryan McCue 2:13 am on November 14, 2013 Permalink

        We’re still incompatible in numerous other ways, like: tabs instead of spaces (yay tabs!), opening braces for functions/etc being on the same line (yay!) and my old favourite, spaces everywhere (BOOOO). :)

    • Weston Ruter 6:21 pm on November 13, 2013 Permalink

      +1

      Filed a issue to add this to the PHP_CodeSniffer rules: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues/124

      By the way, we’ve been working on a script for PHP_CodeSniffer which will only apply the rules to files and the lines in these files that have changed, that is, it will only report errors on uncommitted code. This would make PHP_CodeSniffer suitable for use in WordPress Core, as it would guide developers to apply the rules for new code but leave old code alone. The script is called phpcs-patch: https://github.com/x-team/PHP_CodeSniffer/blob/phpcs-patch/scripts/phpcs-patch

    • nofearinc 6:28 pm on November 13, 2013 Permalink

      That’s incredible improvement given the hundreds of issues with the copy-paste of a second statement added to an if clause getting executed outside.

      As a reminder, we’ve been adhering to this in Java for a long time – http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#449

    • Scott Taylor 6:31 pm on November 13, 2013 Permalink

      I’d grown to like bracelessness, but ok. #thanksobama

      • Mike Schroder 9:55 pm on November 13, 2013 Permalink

        Yeah. I tend to agree that some statements *look* better without the braces.

        But, in terms of core, it seems safer to begin requiring them — at the very least for new code.

    • Peter Chester 6:36 pm on November 13, 2013 Permalink

      +1 I’ve always felt that explicit braces improve legibility.

    • Ian Dunn 6:40 pm on November 13, 2013 Permalink

      +1 because of consistency (internally and with the JS guide), and not having to add braces for debugging and then remove them.

    • Beau Lebens 6:47 pm on November 13, 2013 Permalink

      I’d definitely agree with this. My 2 biggest reasons would be consistency with JS, and ability to add/remove debug info easily without introducing bugs.

    • Tom Auger 6:47 pm on November 13, 2013 Permalink

      +1 even though I like the no braces construct myself, I definitely agree for all the reasons Nacin lists.

      • Tom Auger 6:50 pm on November 13, 2013 Permalink

        Although, what about allowing 1-liners, like:
        if ( $braceless_condition ) echo “1 – liner only”;

      • Franz Josef Kaiser 9:13 pm on November 13, 2013 Permalink

        And what about one-liners like this one?

        defined( 'ABSPATH' ) OR exit;

      • Andrew Nacin 11:06 pm on November 13, 2013 Permalink

        But this whole thing was about taking one-line conditions and always requiring braces. One line, no line break was against our current standards and would continue to be against these.

        A construct like defined( 'WPINC' ) or exit; remains OK — of course, in limited use, pretty much only for this right here.

    • Stefano Aglietti 6:55 pm on November 13, 2013 Permalink

      IN my day developping of theme plugins etc I qlways add braces even for single line i prefere, less problem if code evolves and editor i use (PHPstorm show better the code and it show up clearer. +1 to Nacin proposal

    • Marcus 7:00 pm on November 13, 2013 Permalink

      Yes please!

      Lack of braces is one thing I really dislike about the WP coding structure but have learnt to live with.

      I use braces by habit and aside from easier readability, it avoids copy/paste errors or editing code. Would love to see that practice in core too!

      As Tom Auger suggested, I think one liners are acceptable and do use this approach these days, mostly thanks to the code in core :)

    • Ryan Hellyer 7:16 pm on November 13, 2013 Permalink

      I recall finding conditionals very confusing when I first started out. I immediately grok’d how braces worked, but “if ( bla == blob ) : ” confused me, and omitting braces or and endif REALLY confused me.

      I’ve grown to not care about this issue, but I suspect I’m not the only person who got flummoxed by this when they first started out.

      I started using braces for (almost) everything about a year ago, but had been omitting them for a long time as I thought they were the recommended practice since I saw them in core all the time.

    • Per Soderlind 7:27 pm on November 13, 2013 Permalink

      +1, I allways use braces, been using them since I learned C in the 80ies, even for 1-liners

    • Doug Wollison 7:32 pm on November 13, 2013 Permalink

      +1, especially on the consistency with JS angle; might as well get them as close as possible.

    • Jeff Rose 7:32 pm on November 13, 2013 Permalink

      +1 I’m a relative newb, but I much prefer the explicit braces and consistency

    • Paul Gibbs 8:11 pm on November 13, 2013 Permalink

      I support leaving the code standards as they are. I prefer leaving braces out on short, simple, and uncomplicated IFs because there’s less visual noise to read when you are scanning code; it makes the code more readable, as is briefly alluded to in the post.

      It is always possible for accidents to occur when writing or reviewing code; without leaning too heavily on the example given, any codebase will still occasionally receive other similar, easily-overlooked errors. Requiring braces will just change the type of problems and their consequences. I don’t see a net win here.

      Using IDEs for development can also make it easier to debug or inspect values at certain points in execution with breakpoints. It’s something I am trying to do more often in my own work, because it stops me making any changes to the codebase that I’m rushing through, perhaps making quick and messy changes for debugging! Sometimes a debugger is a better tool than print-based debugging, though of course, the inverse is also true.

      • Ryan McCue 2:15 am on November 14, 2013 Permalink

        One of the other reasons it’s nice is that it reduces noise in patches. Adding a line to a single line if means changing 3 lines, which is visual noise when you’re reviewing. I like excluding them occasionally, but the diff noise is what ruins it for me.

    • Joan Boluda 8:21 pm on November 13, 2013 Permalink

      +1 because of consistency

    • John Blackbourn (johnbillion) 8:44 pm on November 13, 2013 Permalink

      I’d like to discuss this during today’s meeting

      I think we have better things to discuss. Please just do it and save everyone a mostly pointless conversation.

      • mattyrob 9:43 pm on November 13, 2013 Permalink

        +1 to that ;) And the original idea too.

    • Matt van Andel 9:17 pm on November 13, 2013 Permalink

      I have but one thing to say about this…

      YES

    • Lance Willett 9:50 pm on November 13, 2013 Permalink

      +1 even though I’m used to it, the reasons you mentioned outweigh the habitual.

    • Chip Bennett 10:41 pm on November 13, 2013 Permalink

      +1, which, coming from the resident pedant, should come as no surprise. :)

    • Mike Schinkel 10:42 pm on November 13, 2013 Permalink

      Like Matt van Andel said:

      YES!

      This will make it possible to set breakpoints for debugging on all lines of code with PhpStorm (and other PHP IDE debuggers.)

      And if you are looking for the first candidate for this, please update template-loader.php with this new standard, or bless the task and I’ll do it.

    • Arnan de Gans 11:04 pm on November 13, 2013 Permalink

      I agree with this idea :) plugin and theme makers should do this also.

    • Robert Chapin 12:43 am on November 14, 2013 Permalink

      Braceless ifs always bothered me, not because of inserting extra lines, but because PHP also supports two braceless ‘else’ syntaxes that confuse the hell out of me.

    • Brad Davis 12:45 am on November 14, 2013 Permalink

      +1.

    • jarednova 1:37 am on November 14, 2013 Permalink

      +1. Braceless-ness is one of those “timesaving” things that actually costs more time. Clarity > Brevity

    • photocrati 3:06 am on November 14, 2013 Permalink

      You’re just kickin’ in an open door with this suggestion …

    • Edward Caissie 3:11 am on November 14, 2013 Permalink

      As my alter-ego said … you’re kickin’ in an open door with this suggestion.

    • Andrew Nacin 4:21 am on November 14, 2013 Permalink

      This proposal was accepted during the Wednesday meeting. I’ve updated the coding standards handbook page. We’ve yet to discuss what we’ll do for old code, but all new and changed code should receive braces.

    • Nashwan Doaqan 11:01 am on November 14, 2013 Permalink

      +1 even though I’m used to it, I will update all my plugins code :)

    • Tom McFarlin 1:58 pm on November 14, 2013 Permalink

      +1.

    • contempoinc 6:12 pm on November 14, 2013 Permalink

      +1

    • Danny van Kooten 6:33 pm on November 14, 2013 Permalink

      +1

    • Barry Kooij 6:48 pm on November 14, 2013 Permalink

      +1

    • dimitrov.adrian 8:19 am on November 15, 2013 Permalink

      This is good approach, but I think that this is right time to suggest some more things. It’s about the space usage.

      my_function( $param1, func_param( $param2 ) );

      why just not

      my_function($param1, func_param($param2));

      IMO in most cases this make code more hard reading

      Also, I think using of predefined constats (true, false and null) should be in uppercase – TRUE, FALSE and NULL

      In this order I think that code standards of Drupal (https://drupal.org/coding-standards) can help here, as they try to follow PEAR code standards.

      • Christian Foellmann 10:40 am on November 15, 2013 Permalink

        I dont think we should change one of the most basic conventions of WP coding standards.

      • Andrew Nacin 1:50 pm on November 15, 2013 Permalink

        Sorry, I can’t ever see these rules being changed. Long live whitespace. Let the code breathe. :-)

    • Christian Foellmann 10:36 am on November 15, 2013 Permalink

      +1 for “always require braces”

    • Gregory Karpinsky 12:10 pm on November 15, 2013 Permalink

      +100000!!! Finally!

  • K.Adam White 9:48 pm on November 5, 2013 Permalink
    Tags: coding style,   

    JavaScript Coding Standards 

    The PHP files in WordPress core become cleaner and easier to read with every release, thanks in part to our standards for PHP code style. Our JavaScript, on the other hand, hasn’t gotten nearly enough love. This post is intended to open up the recent discussion around JavaScript style to the greater community so we can make up for lost time.

    Don’t we already have a style guide for JavaScript?

    Back in March, @tommcfarlin added a set of coding standards for JavaScript to the developer handbook. These WordPress JS coding standards are a great work-in-progress, but weren’t fully comprehensive (leading to some comment threads clarifying various areas). More importantly, without any clear implementation plan the style guide failed to gain traction.

    At WordCamp Boston’s core contributor day I revisited this style guide with @mattwiebe and Corey Frang (@gnarf37). It is important to identify *and implement* conventions for JS style ASAP because syntax issues in the JS within WordPress may hide latent bugs, and inconsistent code discourages contribution. Focusing on implementation lead us to look for an existing, proven JS style guide with a .jshintrc file (a set of configuration options for the JSHint code quality tool) which we could adopt largely as-is: Getting JSHint in place lets us see the biggest issues in our JS, so we can begin tackling them incrementally (perhaps in the same manner as the inline docs effort).

    After looking at Idiomatic.js and several other widely-adopted JS style guides, we feel the jQuery Foundation’s jQuery Core JavaScript Style Guide guide is the closest match for what we need in WordPress.

    Adopting the jQuery Core JavaScript Style Guide

    jQuery’s guide shared WordPress core’s love of white space—the same “when in doubt, space it out” mantra from the existing JS style page. Moreover, jQuery’s code conventions have been referenced in trac tickets as an example of how we should be writing our code. Adopting their guide wholesale capitalizes on our stylistic similarities, and will let us adopt their .jshintrc and any future code quality tools they write with minimal changes.
    (More …)

     
    • Pbearne 9:55 pm on November 5, 2013 Permalink | Log in to Reply

      I will be happy do a bit of this.

    • deltafactory 9:57 pm on November 5, 2013 Permalink | Log in to Reply

      I’ve been thinking about threequals and curly-braces since Boston. It’s hard to break the habit.

      I’d like to help with the cleanup effort. It would benefit me to familiarize myself with more of the JS bits of WordPress.

    • Mike Bijon 9:58 pm on November 5, 2013 Permalink | Log in to Reply

      After reading the summary in email, my only concern was jQuery’s use of double-quotes vs. ours … seeing the longer article, that’s handled and I can’t think of any reasons to object.

      On the + side, adopting jQuery’s standards wholesale should reduce maintenance & debate. Plus, getting started sooner than later to *any* standard should help speed JS work & maybe help a few overly-debated JS tickets in Trac.

      Looking forward to seeing the sprint schedules

    • adamsilverstein 10:27 pm on November 5, 2013 Permalink | Log in to Reply

      Great post, thanks! I will try to make the meeting tomorrow and assist in the cleanup effort.

    • Matt Wiebe 10:46 pm on November 5, 2013 Permalink | Log in to Reply

      I have another (virtual) meeting at the same time, but I should be able to chime in.

      Thanks for pushing this forwards @kadamwhite :)

    • ericsherred 10:59 pm on November 5, 2013 Permalink | Log in to Reply

      Sounds like fun to me.

    • Dion Hulse 12:07 am on November 6, 2013 Permalink | Log in to Reply

      Wouldn’t it be better for us to standardise on for ( var i = 0; i < 100; i++ ) { instead of including var outside of the iterator? IIRC, including it outside was for some rather old browsers that we no longer (and probably haven’t for a long time) supported.

      • Andrew Ozz 1:12 am on November 6, 2013 Permalink | Log in to Reply

        As far as I remember defining all vars at the beginning of the scope mimics the actual way the script is parsed. Don’t think defining vars in the middle or end was a problem in any browser.

        • Dion Hulse 1:19 am on November 6, 2013 Permalink | Log in to Reply

          I thought I’d heard a rumour of an early IE bug.. but you’re probably right, defining it earlier is most likely only a parsing optimization, something we probably don’t need to worry about.

        • Tom McFarlin 1:52 am on November 6, 2013 Permalink | Log in to Reply

          +1 to this.

          Including all var declarations at the beginning of the function is how the script is parsed, and for those who are fans of JSLint, you’ll notice that combining all var declarations together is preferred[0].

          0.http://www.jslint.com/msgs.html

        • K.Adam White 2:14 am on November 6, 2013 Permalink | Log in to Reply

          As Tom notes, Andrew is correct—Variable declarations are “hoisted” to the top of the function’s scope, so declaring all your variables first is a best practice (it unifies the code’s visual structure with how it is parsed by the JS engine). There’s actually a “onevar” parameter in JSHint to enforce this style.

      • WraithKenny 2:10 am on November 6, 2013 Permalink | Log in to Reply

        I think it’s better, considering `for ( i = 0; i < 100; i++ ) { … } … var i = 2; alert( i );` would be confusing ('100') because of hoisting.

    • Andrew Ozz 1:47 am on November 6, 2013 Permalink | Log in to Reply

      Re-reading jQuery Core JavaScript Style Guide again: apart from the single/double quotes, other differences are the lack of indentation for `case` in `switch` and the hard limit to 100 characters per line (counting tabs as 4 chars). All of the rest more or less match our PHP and current JS coding standards. We also (used to?) have few more, like the strong discouragement of using nested ternary operators.

      So the question is: should we adopt the jQuery standard “wholesale” and depart from our PHP coding standard or should we continue to keep our PHP and JS coding standards as close as possible?

      • Tom McFarlin 1:58 am on November 6, 2013 Permalink | Log in to Reply

        I’m for the adoption of jQuery standards as much as possible; however, I do err on the side of keeping the JavaScript closely-related to our PHP coding standards (which is what I tried to do with the first draft of the standards).

        The reason being is that I don’t think we, as developers, should have to maintain two different set of standards.

        When working on client-side code, I often find myself thinking What’s the server-side standard for this, again? and then I try to apply that.

        Because I – and I’m sure most of us – are so familiar with the PHP standards, perhaps we should implement a “when it doubt, default to PHP standards.”

      • K.Adam White 2:26 am on November 6, 2013 Permalink | Log in to Reply

        I’m of a case-by-case mind on this. For example, I’ve encountered very few situations where >100 characters in a line were truly needed (and not just a symptom of hard-to-read or overly-nested code), so I’d be inclined to keep that. On the flip side, I’m all for keeping indentation rules consistent with PHP.

        Thanks for raising these questions, this is exactly what we need! Both here and during tomorrow’s chat I hope to identify any other differences between our PHP style and the proposed guide, and make decisions about which way to go. We’ve already identified a few areas in which we want to go a different way than jQuery. It’s a useful set of default behaviors, but what style guide we adopt isn’t what’s important—what is important is that consistency.

        • Andrew Ozz 2:47 am on November 6, 2013 Permalink | Log in to Reply

          Yes, the “around 80, max 100 chars” limit might eventually surface when something has many levels of indentation (5 – 6 tabs). This is not so hard to hit with longer jQuery chains which should probably be broken on multiple lines. Thinking it may be nice to have it as a rule in the PHP coding standard too, just not sure if it needs to be enforced.

    • Tom McFarlin 2:02 am on November 6, 2013 Permalink | Log in to Reply

      I’m going to try to make it to the meeting – what server and channel will the meeting take place?

      • K.Adam White 2:12 am on November 6, 2013 Permalink | Log in to Reply

        Good point, that’s something people need to know: Freenode, right in #wordpress-dev. (Note: That time was selected because I was not aware of any conflicting meetings; If anybody has a meeting in #wordpress-dev scheduled at that time, please let us know and we’ll get another room!)

    • Paul Clark 4:09 am on November 6, 2013 Permalink | Log in to Reply

      Count me in for a JSHint sprint!

    • Gary Jones 9:22 am on November 6, 2013 Permalink | Log in to Reply

      Not sure I can make it tonight, so I’m leaving my thoughts here that hopefully someone can take into consideration during the meeting.

      General adoption of the jQuery standards: +1
      Two exceptions to those standards: +1

      Would like to see a push towards named rather than anonymous functions = more self-documenting code, fewer nested levels -> avoid hitting line limits, reduce complexity.

      Consider use of ‘es3′ option in .jshintrc, since WP still needs to support IE8-9, and that will catch use of reserved words being used as properties with dot notation etc.

      I’m up for helping out with some JS tidying.

    • K.Adam White 1:00 am on November 10, 2013 Permalink | Log in to Reply

      Just a heads-up for everybody waiting for an update on this: Hang tight for a day or two, I’m working with @kpdesign to get the JS Standards handbook page updated and up to our standards.

    • Lance Willett 3:36 am on November 12, 2013 Permalink | Log in to Reply

      Thanks for your work on this—more vigorous standards and cleaner code FTW.

  • Peter Westwood 9:18 am on November 2, 2010 Permalink
    Tags: coding style   

    I added a little to the file naming section of the WordPress Coding Standards to clarify the way in which we name our class files.

    In summary class files will be named using hypen separation and based on the class name they contain.

    I won’t be changing the name of old files but have updated the files we added in 3.1 before it’s too late.

     
    • Mike Schinkel 10:00 am on November 2, 2010 Permalink | Log in to Reply

      Glad you posted this. I’ve been meaning to ask and this seems like a great time. In core, some functions use a leading ‘wp_’ like wp_insert_post() whereas other functions don’t, i.e. update_post_meta(). Try as I might I’ve not been able to decipher a pattern but I’m sure one is in there I just haven’t been able to grok it.

      So when and why does a core function get a wp_ prefix and when not? Also, if there is legacy involved and some functions don’t follow the rationale, will they be cleaned up over time?

      This one has bugged me for a while… Thanks in advance.

      • Ozh 10:26 am on November 2, 2010 Permalink | Log in to Reply

        I think at the origin the wp_* functions were more private stuff used within APIs, but this has evolved without real guidelines

        • Mike Schinkel 10:45 am on November 2, 2010 Permalink | Log in to Reply

          Thanks for the reply. Would it make any sense to start some guidelines if none exist? If there are none it would seem like wp_ prefix might be consider reserved so a best practice would be to never name a function or variable starting with wp_ and then WordPress would be free to use that namespace for future enhancements?

        • Peter Westwood 10:47 am on November 2, 2010 Permalink | Log in to Reply

          @Mike: Actually best practise is for plugins/themes to prefix everything with something. That way they never clash with core or each other.

          I tend to prefix with my initials or the plugin slug.

    • Ozh 10:25 am on November 2, 2010 Permalink | Log in to Reply

      Any reason for the file naming scheme other than having something consistent and pretty to the eye?

      • Peter Westwood 10:28 am on November 2, 2010 Permalink | Log in to Reply

        I went with consistency to the existing rules which stated separate with hypens and just documented the current practises.
        Personally, I prefer the class. and functions. that BackPress uses but I also don’t see a need to change WordPress in that direction – what we have works fine.

        • Andy Skelton 7:36 pm on November 2, 2010 Permalink | Log in to Reply

          I value filenames that can be autocompleted with few keystrokes. My only material objection to a new filename is one that increases the number of keystrokes to access an old file.

    • scribu 4:05 pm on November 2, 2010 Permalink | Log in to Reply

      For context: #15280

    • Jacob Santos 6:12 pm on November 2, 2010 Permalink | Log in to Reply

      else if or elseif section:
      “Both notations are used in conjunction with curly brackets, there is no rule which to prefer. elseif can save you some hassles sometimes.”

      Problem 1: WTF?

      Problem 2: The point of a standard is to specify which is used for consistency. This is not a standard and therefore does not belong.

      Problem 3: elseif vs else if is only a problem when using if() : elseif() : else: endif;. Since this is rarely if ever used in WordPress, it makes more sense to use “else if” instead.

      “If you forget an equal sign it’ll throw a parse error instead of just evaluating true and executing the statement. It really takes no extra time to do, so if this saves one bug it’s worth it.”

      These bugs are certainly hard to find, however, if this is the case, then it also makes sense to never have any assignment in the if statements. This may go against the previous rule where variables aren’t created unless they are used more than once. It is worth it for consistency. It should be noted that assignment already exists in the if statements now confusing the standard.

      The “Self-Explanatory Flag Values for Function Arguments” Section.

      Most people solve this by simply using constants, it might be something to look into.

      • Andrew Nacin 7:21 pm on November 2, 2010 Permalink | Log in to Reply

        I’m working on a new coding standards document. In it, I’ve proposed s/else if/elseif/ and I plan to make that change across core.

        I don’t mind assignment in the if statement. We just need to be worried about left-hand comparisons.

        Re: function arguments: I’d rather a string any day.

        • Jacob Santos 8:19 pm on November 2, 2010 Permalink | Log in to Reply

          The mistaken assignment is most often a novice mistake and often corrected with simple peer review. When you have assignment in an evaluation statement, it confuses the reviewer as to whether you made a mistake or if it is intentional. It is considered best practice in that instance to always do assignment outside of evaluations for clarity and to let those reviewing the code know that you’re not making a mistake.

          Coding standards aren’t always preference, when working with others they should be considered for ease of review, clarity, beauty, and preference last.

          It also appears that certain aspects are being drawn from compiled languages and applied to interpreted ones without discerning why certain standards are applied to compiled and why those similar instances do not apply to languages like PHP.

        • hakre 11:13 pm on November 3, 2010 Permalink | Log in to Reply

          @nacin – I asked multiple times when the coding standard gets actually applied it to the wordpress codebase. I even offered help for that multiple times but I can not see any traction for months. Shouldn’t this something be done prior to a new point release? Is this actually something to expect or is the coding standard just to fill up a codex page?

        • Peter Westwood 8:09 am on November 4, 2010 Permalink | Log in to Reply

          @hakre: Coding Standards are always a guide. It is a waste of everyones time and effort going back and applying them to legacy code.

          They are all about promoting consistency going forward.

          We do not need to create unnecessary churn in the codebase as this just increases the test burden.

        • hakre 1:59 pm on November 4, 2010 Permalink | Log in to Reply

          The argument of legacy code can be left aside. The coding standard is not applied to new code as well. This might be about promoting something but not about actually doing it.

          But I didn’t pose my question that some might think they need to defend themselves, I mean this package is the work of many and as peter stated, this is all about promoting consistency going forward.

          Instead I wanted to find out if we can see some traction for this in the near future or not?

          We last talked about the coding standards before the hiatus and it was said that it will become applied to the codebase (IIRC the statement was by you Nacin). At least it sounded like quite a plan. This was somehow related to the sourcecode documentation on the wordpress website, this probably helps you to remember what I mean.

  • Peter Westwood 10:04 pm on February 13, 2008 Permalink
    Tags: , coding style   

    clearing up after rboren

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel