if (hours < 24 && minutes < 60 && seconds < 60)
{
if(hours % 2 == 0)
return true;
else
return false;
}

I have tried a variety of styles, and gravitate back to good old K & R (mostly). I see the structure immediately via indenting, without needing to count or balance brackets – kind of like Python with closing delimiters. Additional bracket-only lines just clutter the landscape for me (except the opening of a function definition – there it helps set that apart from control structures).

Allman style has consistency having all braces on lines by themselves, balanced. K&R has consistency in closing braces always being at the start of a line, opening at the end, which you can treat as syntactic sugar around the control flow keywords. Each type of pattern has its positives, which appeal to some more than others.

I disagree somewhat about formerly limited screen space as the only reason for K & R – even if you have 100 lines of code visible on a rotated 24″ screen, there is a balance for best visual comprehension between packing code too tightly and too loosely. For me, K&R works – along with leaving empty lines where ever it makes the code easier to read.

I think it would be interesting to set up one of those eye-focus-point detectors that psychologists like to use, recording how programmers view a program – where their eyes jump as they try to absorb both the structure (forest) and the trees (individual statements and expressions). I believe that excessive vertical displacement can be a tad slower to comprehend, similar to paragraphs which are too wide.

Allman might make it easier to find unbalanced braces – but there are editor tools to help with that, and timewise finding unbalanced braces is a small part of program review and modification.

But your milage may vary; I don’t think there’s a universal best style. I try to follow the existing style when modifying code.