Some random conventions, I'll add more as I remember
###Choosing label names
Routines that act like game loops get names such as run_<action>
Routines that primarily delegate many related tasks get the name <task>_handler
Routines that are global trampolines for a local routine get a suffix of <routine>_global
Use sublabels whenever possible, nesting deeper is okay but should be used sparingly
Relative labels should be used minimally when a name wouldn't help the context (Like a spinlock)
Strive for descriptive names, ideally under 30 chars but absolutely never exceeding 36
Anything in the global namespace should be specific to reduce chances of name conflict
Underscores only.
Use of # should generally be temporary (code actively being documented) or if rarely used when it
helps routines with multiple entries or similar conditions
####Data naming notes
Data which is local should get a sublabel
Palettes should get the _palette suffix
Layer graphics should get the _tiledata suffix
Layer tile maps should get the _tilemap suffix
Collections of sprite graphics should get the _graphics suffix
Single sprite graphics should get the suffix _frameN where N is optional (used for when multiple frames exist)
When practical, ROM data should get a struct defined in structs.asm This allows for named member access
###Comment structure Its best to allow comments to flow around the code to cluster related opcodes. Try to comment on what is happening and why it is happening more than how it is happening. The hard limit for line length is 120 chars. Do not exceed this with comments. If you need a bulk description for some reason place it in a block before the routine. Never use the macros as a comment trick.