I didn't say optimal in the aspect of performance, and no, it doesn't look professional. It looks cluttered, and it isn't consistent with the typing conventions this language uses.
From my own perspective it strikes me as absolutely amateur to go about that route.
Then I shall forever be an amateur.
As long as the necessary whitespace is preserved and the code is presented in a human readable format, there's absolutely no need to argue about curly braces.
As long as the code you write is consistent, and you aren't working with others that have a totally different style, then it's no big deal.
Areas that do kind of matter at a smaller level, though, would be things like variable notation and code segmentation.
I've picked up some different styles of writing code, but these are my general patterns:
Indendation style:
Doesn't make a difference to speed, but when you group code together into indentation level blocks like this rather than doing:
Later on down the road, someone can splice some code in like this:
This can lead to project structure that's really difficult to learn, so I don't like to use the collapsed path approach. At the compiled level, it doesn't make a difference, though.
Variable notation:
Instance variables are always lowercase at all parts. words should be separated by underscores for readability. A leading underscore means that the variable is protected --basically, you can read the variable, but don't write to it. Usually this variable is accompanied by a setter. A double leading underscore means you should pretend the variable doesn't even exist. Don't touch it, don't read it, don't even breathe on it funny. It's very important for an internal piece of code that you shouldn't have to touch, and if you aren't careful something can get messed up when you change it. This is usually for variables that store the state of a system that should be interacted with through procs/verbs.
Proc notation
Global procs should be all lowercase with underscores between words. A double underscore means that the function is called internally and you should never have to call it yourself.
Instance procs should be in CamelCase unless it is an internal proc (double-underscore prefix, same format as global), or it begins with a certain prefix. camelCase indicates that this function is generally something that you will be using frequently to interact with the object's particular state. CamelCase procs are generally body behavior for state changes.
Verb notation:
Argument notation: (Thanks KaioChao)
Arguments should always be capitalized in instance procs, and lowercase in verbs and global procs. Except for arguments introduced into DM's syntax by LummoxJR. Those should always be lowercase, because Lummox doesn't follow Dan-standards. (Ya jerk! ;P)
Verb arguments always lowercase, thanks to Dan standards (That jerk too! ;P)
Variable definition:
Always at the lowest possible code path, except when loops are involved. Never define variables inside of a loop.
Type naming conventions:
Datums should be CamelCase, and atoms should be lowercase with words separated by underscores.
I've got a few other standards... But you know, they aren't that important. These are just the basics I try to use to keep my notation consistent.