Related to this comment: Nr. of edits make community wiki? Why not nr. of users?

Would it be useful/beneficial to establish a site convention, such as the official WordPress coding standards, for editing/refactoring code in questions/answers?

Note: I am asking specifically about community edits of posted code, not about requiring users to understand/use such a standard merely to ask/answer a question.

Apparently, there is an issue in which too many edits to a question/answer result in that question/answer being auto-converted into a community wiki. @EAMann expressed a concern that such auto-conversion might be getting triggered by multiple/trivial edits to questions/answers, merely to edit/refactor code. One way to prevent such multiple edits would be to establish a code standard/convention to use when making code edit/refactoring edits. That way, any additional edits to could would, presumably, take place merely to improve the functionality of the code, rather than the layout/presentation of the code.

Thoughts?

share
add comment

3 Answers 3

up vote 8 down vote accepted

I think this would be valuable in that it doesn't get too granular. Everyone has a different code style preference (i.e. spaces before/after function params, if/else bracket placements, etc...). I don't think conforming everyone to one code style will work on WPSE as this could create more edits for those wishing others to stick to the letter of the law.

What I would see as beneficial is an editing standard that includes the following:

  • Proper indentation for legibility (only if needed)
  • add_action/filter be placed prior a callback to help others follow logical progression
  • Correction of bad (really bad) custom function names that might/would interfere with other plugins or core. This would lend to a more quality code example for subsequent users who might copy/paste while looking for a solution.
  • As SE provides syntax highlighting, there is no processing for syntax errors. Any answer/question with improper sytax SHOULD be edited immediately.
  • At times, obscure variable names make questions extremely hard to follow. This leads to a lack of answers or off-question answers. IMHO, an edit is justified for readability sake.

I'll add more if I think of them.

share
    
+1. Especially for prefixing custom functions. To many people would be tempted to just copy and paste. By at least putting something they may at least become aware of limited namespace. –  Stephen Harris Feb 27 '12 at 15:08
add comment

My own code style differs in some significant details from the WordPress style, and I get angry when someone tries to fix that – it happened and I reverted the changes.

So … add line breaks to avoid horizontal scroll bars, add comments – but don’t touch more than that. It may lead to more edits.

Update

Just to make my point more clear: If broken or unreadable code is not the first reason for the edit, then don’t do it just to enforce a code style. If code is broken then it has to be fixed just like any other part of a text.

My current code style is the result of 20 years of experience. I see my code as a designed story that happens to be read by people and to be executed by a machine. Other people see their code probably in a similar way, they just came to a different design result. We have to respect that even if we don’t like it. And I don’t like many code snippets I read here every day. :)

On the other hand: I know how bad my English is. I accept corrections here gladly and with less resistance. When in doubt, ask the authors in a comment to fix the errors for themselves. That is the best way for them to learn something.

share
2  
This reason - personal preferences regarding coding style - is exactly why we would need a mutually agreed-upon coding standard for editing code. I have my own preferences as well, but would be more than willing to subvert my own preferences to an agreed-upon standard, if it would facilitate more meaningful/useful code edits. –  Chip Bennett Feb 27 '12 at 14:21
    
I would never change your code style, not even add a line break. :) I think, some common sense is good enough: Fixing obviously broken or dangerous parts doesn’t need an explicit style guide. –  toscho Feb 27 '12 at 14:33
    
That's fair, too. :) If the community convention is only to change code for obvious errors, then that convention circumvents the entire question of editing code for style/clarity. –  Chip Bennett Feb 27 '12 at 14:34
1  
I'd actually propose sticking to the WP coding guidelines for posted code here. But I understand your reluctance to vary from a personal standard ... for the sake of educating new members in the community, though, would you be willing to conform to a community standard (based on the WP coding guidelines or otherwise) for just this site? –  EAMann Feb 27 '12 at 17:15
    
I hesitate to play the bad guy here … but the WordPress style guide is nothing I would recommend to a new coder. Just take a look at the core files: that mess is the logical result of the current rules. We don’t need fixed rules because our code doesn’t have to work together. Diversity is good. It is more important than readability, the state of single questions or reputation. –  toscho Feb 27 '12 at 19:55
2  
Perhaps I should re-title my question. I'm not stuck on the official WordPress coding standards, but rather an objective standard by which the WPSE community determines whether and how to edit code. –  Chip Bennett Feb 28 '12 at 18:10
    
@toscho I agree with you on diversity. We need that. It's how the WordPress community flourishes. For WPSE, readability is a big issue. If a code example is so obscure that you cannot read what it does, it justifies an edit. No one is going to edit your code or Chip's or anyone who is active here unless they want fire to rain on their head from the author. I think this scenario involves a user who hasn't had a lot of code experience and has presented an obscure, confusing code example. What if a user says their style preference is a 32 char tab indent? Does form absolutely rule over function? –  Brian Fegter Feb 29 '12 at 14:14
    
@BrianFegter, ChipBennett I made an update to my answer to clarify my position. –  toscho Feb 29 '12 at 14:43
    
@toscho Good call on the comment. :) –  Brian Fegter Feb 29 '12 at 14:59
    
Allow me to say that I feel like this discussion is rather "pointless". Most of the users who actually would edit code snippets are part of this discussion or belong to the more experienced users (correct me if my observation is wrong). And any of you guys will write / edit to good, readable code because of a similar mindset. If one prefers brackets / operators on a new line and an other don't...this won't make a real difference to the average non-pro-coder ( designer ), and as someone who somehow belongs to this group: I like to get different ideas from more experience coders. +1 4 diversity –  ungestaltbar Mar 2 '12 at 22:55
add comment

This is what I'd correct:

<?php
if ( true == $this->function() )
                                                 $try_to_catch_me_if_you_don't = 'have_to scroll';

Everything else - aside from the function name clash note from @Brian Fegter - shall imho stay as it is.

And yes: (As always) feel free to edit my code, but...

function dare_to( $move = false, $bracket )
{
    if ( 
        $move 
        AND 'my brackets on new line' == $bracket 
    )
        die();

…as this is my personal coding style and therefore my own decision for improved readability.

share
1  
Again: contrasting personal preferences are exactly the reason that an agreed-upon standard would be helpful when editing code. I don't see why your personal code style preferences, or Toscho's, or mine, should take precedence over anyone else's. –  Chip Bennett Feb 28 '12 at 1:55
1  
@ChipBennett No styles takes precedence over another. They coexist. I would never force my style to other people’s code, and I expect the same respect for my preferences. –  toscho Feb 28 '12 at 3:02
1  
@kaiser I agree because scrolling sucks for readability and it's the only thing that bothers me , well besides maybe spacing. –  Wyck Feb 28 '12 at 7:16
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .