I always use braces for single-line if, while and for.

In my opinion, it reads more consistently, and gives me a solid visual indication of where the block ends.

Moreover, I'm often doing things like adding ad-hoc printf (or rather printk in kernel-space) for debugging purposes. Leaving the brackets in leaves me less prone to errors like this:

if (foo)
    bar();
    printf("%s\n", "bar called");

Linux kernel has a coding style guide:

https://www.kernel.org/doc/Documentation/process/coding-style.rst

Nicer Formatted Version

Regarding your example, I personally prefer the first style. With the second style you will quickly violate this Linux kernel style rule (kernel style has 8-character indentation):

if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Writing code from top to bottom (as opposed to horizontally) is sometimes referred as duffing. I can suggest you this excellent reading on the subject:

Reading Code From Top to Bottom

A scripts/cvt_kernel_style.pl: kernel style source code reformatter.

A script to convert kernel source files to a more conformant style. A supplement to or replacement of Lindent. A wretched little perl script using regexes.

It's a stupid little tool, don't expect it to be perfect. It's not.

Conversions should be done one at a time. Multiple conversions may be performed together, but it's not recommended.

Not all conversions are performed correctly. Verify all conversions before committing anything.

If the original source file doesn't compile, then any conversion will not compile either and may eat your source.

Do not use option --overwrite unless you have another copy of the source file.

No option exists to wrap long lines.

Command line use:

$ ./scripts/cvt_kernel_style.pl --help
usage: ./scripts/cvt_kernel_style.pl [options] <files>
version: 0.1

But better is to know what is the coding style:

Linux Kernel Coding Style (by Linus Torvalds)

This is a short document describing the preferred coding style for the linux kernel. Coding style is very personal, and I won't force my views on anybody, but this is what goes for anything that I have to be able to maintain, and I'd prefer it for most other things too. Please at least consider the points made here:

Chapter 1: Indentation

Chapter 2: Placing Braces

Chapter 3: Naming

Chapter 4: Functions

Chapter 5: Commenting

Chapter 6: You've made a mess of it