As with most questions like these, it depends on what you want to optimize.
For example, if you like to use grep a lot to find Items in your files, it might be worth putting everything on one line. If you find yourself reviewing your files on a small screen like a phone, splitting them up into multiple lines might make more sense.
For me, I find myself needing to look up something I’ve done when answering forum questions and do so from my phone. So I split my Items into three lines:
ItemType Name "Label"
(groups) [ tags ]
{ binding/channel links }
If it were not for the small screen problem, I would put everything on one line so when I grep I get the full Item definition.
As Markus suggests, using tabs or spaces to get everything to line up greatly helps the human eye see the different parts of the Item. Though this is less important if you use multi-line Item definitions. I don’t necessarily do this strictly though. If you have the file separated into sections, I’d only make the Items in one section line up rather than trying to get the whole file to line up.
I strongly recommend using one file per purpose. This will put Items that are most likely to be in the same Groups and be operated in the same ways in the same place. Inside the file you can organize it in other ways depending on what makes sense, like by room, by floor, or by technology. What ever makes sense to you.
When I do have my .items files organized in a certain way (sometimes there are not enough Items to make sense, or it doesn’t add anything) I’ll insert visual landmarks. Something like
//----------------------------
// Sonoff
With white space before it.
I put the definition of Groups as close to the Items that they contain as possible. This isn’t always possible or they address almost all of OH. Thus, if a Group contains, for example, all the SonOff switches, I’ll put the Group definition right under the Sonoff landmark above. If I have a Group for all lighting, I’ll put the Group at the top of the lights.items file. If it is a Group or Item that applies across all of OH (e.g. a notification Item or persistence Group) I have a special “other.items” file where I put those.
Finally, it helps to use the same sort of file and file naming scheme for Items as you do for your Rules. So you will know that lights.items will have Rules that work with them in lights.rules.
As with all advice like this, the primary concern is to be consistent and do what makes sense to you. You’re the one that has to live with these files. 