That’s what I do. There is no point taking up 4 lines for a simple if statement if you can do it on one line.
And the braces should be on their own lines and indented similarly so the opening and closing brace are the same distance from the left. This style is the easiest to read.
These 2 statements completely oppose each other!
I put the opening brace on the same line as the control statement, with a space in between, and the closing brace on its own line, usually with a comment afterwards to say what it is closing (Not really necessary, but it’s a habit!).
Everything inside the control block is then indented 2 spaces.
eg:
if (somecondition) {
someStatements();
}//if
I use the same rule for all control statements, functions, classes, everything. I don’t understand the reason for treating classes & functions differently to any other type of block.
I also never use the 1 line if statements, they always have braces for consistency and ease of seeing what belongs to what. Sometimes it’s easy to miss the fact that an ‘else’ does or doesn’t have a brace after it, and then lose track of whether only 1 thing is executed or more than one etc…
It’s really easy to see blocks due to the indentation - so some lines are used for simple if statements that could be done on one line, for the sake of readability, but no readability is lost by putting opening braces on the same lines as control statements due to the indentation.
That style stems from Kernighan and Ritchie’s style who invented the C programming language.
A minor variation of that is the One True Brace Style (1TBS), where single statement blocks are enclosed in braces too, which is the style that many people use.
Commonly with PHP, people choose a style guide to stick to such as ZEND or PEAR, which also applies the 1TBS. Any variations from that style guide tend to be attacked by other team members, so style guides remain influential for a very long time.
If you’re not working in a team, then it is of course much easier to divert from such standards to arrive at your own unique style.
I know the roots of it and about all the different formatting styles, but I still don’t know why they are treated differently!
Go back and have a read then about Kernighan and Ritchie’s style for C code.
in the original C language, argument types needed to be declared on the subsequent line
Fair enough, would have given people more credit for updating with the times / languages though!
I like to think that it’s a testament to the power of style guides. They stick around because nothing has significantly come along to replace it.
Strunk & White’s book of the Elements of Style retains its influence over the English Language for similar reasons.
I’m all for tradition, but not necessarily tradition for tradition’s sake. Still, if people find that style easier (somehow!), then no problems I guess!
FYI, My style is directly from Sun’s Java Coding Style Guide
I find this to be the most organized, consistent, and efficient way to program in C-style syntax.
Look into it. I think you’ll like it!! 
This is one of the problems that I disagree with. Languages have their own issues and difficulties to deal with, so even if they are superficially similar, one coding style may not be as appropriate as another.
It can be tempting to at times, because then you don’t have to learn different sets of coding styles for different languages, but those differences tend to be there for good reasons.
Use a Java-specific style guide for when writing Java, and a separate PHP-specific style guide for when writing PHP.
The only time I would use Sun’s Java Coding Style Guide for writing PHP is if I’m entering a position at a company that for some strange reason demands you code PHP according to Java’s style guide.
What specifically do you have a problem with regarding Java-style code for PHP? Camel-case naming? JavaDoc commenting (which happens to be identical to PHPDoc commenting)? Other than naming conventions, nothing is very different in Java-style coding…
That’s like wearing someone else’s underwear. Sure it can work, but you’re better off using ones that belong to you.
I find this work best for me:
Monday: I use the PEAR system.
Tuesday: I use the ZF syntax, Monday got me in the groove, but by Tuesday I can rock with ZF.
Wednesday; I usually drink too much - so revert to Mondays’ system.
Thursday: classic C syntax ( with tab set to 2 spaces) it is esoteric but comforting.
Friday: I use Sun’s Java coding style.
Saturday: I drink so much that I neither care nor bother.
Sunday: move all the next weeks’ coding systems up by one.
This might seem confusing but in effect it is very simple, by looking at the various phases of the moon and by holding up to the moon a laser print-out of my code for the corresponding day I can very easily tell how effective my code has been, then I touch some wood, recite the “Hail Mary” three times, backwards, and the answer appears - but of course not the reason for the code.
sigh
When all else fails I write a new thread on sitepoint, and try to desperately divert attention away from my vacid inability to concentrate on problem solving.
I mean, **ck, we’ve all done it!
Not bad, Cups. Reminds me of my approach to all this…
[Leans back in his office chair reminiscing of some distant memory…]
After spinning around 7 times counter-clockwise in my office, jumping up and down on my left foot while holding my right foot behind my body using my left hand, I type each character of each function name and each variable name upon each spinning revolution while singing “American Pie” backwards using the timbre one would normally hear in Led Zepelin’s “Immigrant Song”, and would you believe that I have created an entire CMS platform using 1 incredible line of code complete with MySQL transactions, session handling, registration, module support…!?
One line infrastructure, baby. 
Well, having been a Java coder for years before moving to PHP, lower-case-underscore naming always felt that way for me… awkward and ridiculous. Lower-case-underscore is (in my mind) reserved for DB objects, URIs, XML ids, and other meta-data attributes… not used anywhere else in coding… it just feels wrong for variable and function names, because it breaks the barrier between meta-data and code - a clear separation that I have in my mind. I guess that’s why I stuck with Java naming conventions. I find them way prettier. Actually, I even used camel-case back in the day when I was a MS programmer. It’s just so pretty.
Yeh, I use camelCase for most things in code, and underscores for things like css class names, database columns and table names etc
I like using the space bar and enter key on my keyboard A LOT. I mean why not? Whitespace won’t hamper the code plus it can help space things out and make it a little more readable. Long lines of code are a bane. (I also try to keep things under 80 characters long relative to indentation. Indentation itself is 2 spaces.)
Just a sample code ref:
<?php namespace [Vendor]\\[Project]\\[Package];
/**
* Short Description...
*
* Long Description can span many lines and contain examples or any other
* details. Most cases this portion will be blank.
*
* @copyright [year] [Author|Company]
* @license http://[vendor]/legal/oss/license BSD License
* @license http://[vendor]/legal/pro/license Proprietary License
* @link http://[project].[vendor]/api/[package]/[component]
*
* @category [project]
* @package [package]
* @version $Id$
*/
# 80 char range
#-------------------------------------------------------------------------------
use Some\\OtherA\\Name\\Space as AliasA,
Some\\OtherB\\Name\\Space as AliasB;
/**
* Description and example of the inner workings of this compnent.
*
* @category [project]
* @package [package]
*/
class ComponentCamelCase extends AliasA implements AliasB
{
const
CONST_ONE = 1,
CONST_TWO = 2,
CONST_THREE = 3;
protected // Always protected!
$varOne = 'default',
$varTwo = 'default',
$varThree = 'default';
#-------------------------------------------------------------------------------
/**
* Short Description...
*
* Long Description...
*
* @param string $a description...
* @param integer $b description...
*
* @return void
* @throws UnknownException, KnownException
*/
public function camelCase ( $a, $b )
{
if ( expression ) {
// multi-line action...
// lots of code...
} elseif ( expression ) {
// more multi-line actions...
// more lots of code...
} else {
// fallback action...
// more lots of code...
}
// or, for single line
if ( expression ) // action...
// or put it under...
$arr = array( 'key' => 'value' );
$arr['key'] or $arr[ $key ];
# mixed ( string $a, mixed $b ) + array $global
# throw UnknownException, KnownException
$call = function ( $a, $b ) use ( $global )
{
// action...
};
return $this; // Always return $this unless it must return something else.
}
}
logic, very nice. You’re using 5.3 already? How do you like it?
I go a step further… I use hyphens for class attributes (e.,g. .class-name) and underscores for id attributes (e.g. #page_header) lol. I’m a little ocd. 
PS - Regarding indentation… why not just indent with tabs and let the individual developer decide what that means in their IDE (most IDEs allow you to configure tabs as 2 spaces, 4 spaces, 5 spaces, etc)? I find that tabs are sadly underused by developers who want to control not only how THEY indent, but how YOU indent. When I find a spaced-indentation on a file, the first thing i do is a Find-Replace for tabs.