Case
Generally I write everything in lowercase and composite names in camel case,
example getNextFreeId(). This makes it easier to distinguish one word from
another.
Another style would be to separate words by an underscore (which you often find in C). But that makes it harder to differ between namespace and symbol name.
Constants
Constants are written in CAPS with name parts separated by an underscore,
f. e. AUTH_MODULES.
Yes, I also used the underscore as a separator making it ambiguous when used with a namespace but having it the same way in almost any other programming language makes it much easier to use and understand.
Abbreviations
Common abbreviations are also written in camel case , example getHttpStatus().
Line length
This is totally up to you and your environment. Currently I am mostly working on a notebook. So when using MiWorkplace or RDi the editor area shows around 80 to 120 characters depending on which views I have side by side to the editor area.
But even with a 24“ monitor I would limit the lines to max. 120 characters (hard limit) and pursue to have it even at no more than 100 characters (soft limit).
Monitors may have evolved in the last years giving us a larger space to work on but the human body and the way we read has not changed at all thus having more space doesn’t help much in the way we read. Kevlin Henney has described it extremely well in one of his sessions (Seven Ineffective Coding Habbits of many Programmers).
Indentation
If a block is used (f. e. if or for) I indent the content inside the block
with 2 spaces.
If I have to wrap a statement to the next line I indent the continued statement on the next line with 4 spaces.
I never use the continuation characters ... to split up a name. In fixed format
RPG you sometimes had to use the continuation characters but in **FREE RPG you
don’t have to use them any more.