Jump to content

Recommended Posts

It pretty much all comes down to personal style and what you find to be the most readable.

 

I personally prefer the second way, with the brace on the same line as the function (or loop or condition, etc).  Lots of people prefer the first way. 

 

If it's just your own project and code then use whatever method you like and find easiest to use.  If your developing code for an open source project or employer you should check if they have any established code style guidelines/rules.  Some places will have a document that dictates things like this (as well as spaces vs tab, indent length, argument spacing, etc).

 

This is pretty much what I do... braces on the next line unless it is a 1-line if statement.

<?php
function foo($bar = false)
{
    if($blah = 5)
    {
        switch($do)
        {
            case 1:
                bar();
            break;
            case 2:
            default:
                bar2();
            break;
        }
    }
    
    if($blah = 1) {
        $oneLineIfStatement = true;
    }
    
    foreach($x as $key => $value)
    {
        // do something
    }
    return false;
}
    
class fooBar extends bar
{
    public $doodad;
    
    public static function something( )
    {
        return false;
    }
}

I think it just depends on what you first saw when learning.

For me, I started off with the braces on the same line and evolved to the second because of standards with projects I worked with. However I do find it cleaner now.

 

Same here. Although I still don't like my conditional brackets being on the next line. I don't know why, it just doesn't look good to me.

For me, I started off with the braces on the same line and evolved to the second because of standards with projects I worked with. However I do find it cleaner now.

 

Thank God! I thought that most people went with the same line brace! Glad to know that some projects do use the second style. Which projects were they if I may ask?

Thank God! I thought that most people went with the same line brace! Glad to know that some projects do use the second style. Which projects were they if I may ask?

A few for work (which I am not allowed to disclose) and Flingbits, a similar site to this that a lot of people from here helped out on... but sadly the drive behind it has died.

<?php
class someClass{
    private $var;

    public function foo(){
        //Stuff
        switch($var){
            case 1:
                //stuff
                break;
        }

        if($var){
            //Stuff
        } else{
            //Stuff
        }
    }
}

I can't stand the break being indented in a case like that. It makes it so much harder to see when the case ends. It's actually one code standard I will break.

<?php
switch($foo)
{
    case 'blah':
        $do->this();
        break;
    case 'something':
        $do->that();
        // and this.. no break!
    case 'else':
        $do->both();
        break;
    default:
        $do->die();
        break;
}

vs.

<?php
switch($foo)
{
    case 'blah':
        $do->this();
    break;
    case 'something':
        $do->that();
        // and this.. no break!
    case 'else':
        $do->both();
    break;
    default:
        $do->die();
    break;
}

 

Personal opinion, but I think the second is so much easier to read with where the cases start/end.

I can't stand the break being indented in a case like that. It makes it so much harder to see when the case ends. It's actually one code standard I will break.

<?php
switch($foo)
{
    case 'blah':
        $do->this();
        break;
    case 'something':
        $do->that();
        // and this.. no break!
    case 'else':
        $do->both();
        break;
    default:
        $do->die();
        break;
}

vs.

<?php
switch($foo)
{
    case 'blah':
        $do->this();
    break;
    case 'something':
        $do->that();
        // and this.. no break!
    case 'else':
        $do->both();
    break;
    default:
        $do->die();
    break;
}

 

Personal opinion, but I think the second is so much easier to read with where the cases start/end.

 

Weird. I find the first one MUCH easier to read and see where each case breaks.

Weird. I find the first one MUCH easier to read and see where each case breaks.

 

That doesn't make sense. You have to specifically look for the break. If you only indent the code in the case but not the break, you know that as soon as the indentation stops there is a break. It is a lot faster to just look at a column of indented text than to find a specific keyword.

I prefer code that is commented. That way, whatever style used, I know how to understand what is written.

 

Side note, I never thought to use break statements as "closing brackets" to the case "open bracket". I'll be trying it out to see whether it improves my ability to organize my switch statements.

Weird. I find the first one MUCH easier to read and see where each case breaks.

 

That doesn't make sense. You have to specifically look for the break. If you only indent the code in the case but not the break, you know that as soon as the indentation stops there is a break.

No you don't, it could be the next case. You are looking for two non-indented lines.

It's kind of silly to tell someone they don't know what's easier for their own self to read. Studies show all-caps is hardest to read but some people insist it's easier for them to read, are you going to say they are wrong and don't know their own comfort?

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.