pubby wrote:Assembly doesn't nest, and the control flow it produces often jumps around in a way that can't be represented with indentations (i.e. the control flow is irreducible). The moment you break the indentation rules for an unusual jump, the advantage of indenting goes out the window because it's not consistent anymore.
I don't believe there is a way to indent assembly in any 100% consistent way.
However, I feel there's a lot of value in visual information from indentation, and just because some cases won't fit a structure exactly doesn't mean that it can't be helpful to indicate cases that do, and can even apply in a useful way to cases that don't quite.
In most cases, I add an indent after a branch, and that indent will end at the end of the code it jumps to. For "if, else" style, there's a brief break in the indent at the else. This makes the length of the branch and its structure instantly readable visually, and I can quickly skim to the end of the structure without having to read the code in between. These two cases covers probably 95% of indents in my assembly code. Especially when nesting simple decision branches within a larger if/else, this make it very easy to see the hierarchy and extent of what's happening there. (
typical example)
Sometimes it gets weird, and I'll make a decision whether to indent or not. It's not necessarily consistent with the rest of my code, but this is because assembly code structures are not consistent. I simply make a decision about how I think I would best read the indent when I'm trying to come back to this code in the future, and leave it that way. Sometime that means a flat/unindented style. Sometimes that means indents that don't match other uses quite. Sometimes that means an extra comment or two to clarify.
The bottom line is that the indents are there to make something easy to read. They're not information for a computer or a compiler, so they don't need to fit some formal and absolute definition of structure. The tabs are merely a visual tool.
If I was writing code that was part of a library for a company that is selling the code itself as the product, however, and not something for my own use, most likely a non-indented style would be mandated for assembly, partly for the consistency, but mostly for traditional practice. It is simply the "standard" appearance of assembly code, and probably worth using as a lowest-common-denominator that nobody would be able to say is an unexpected or irregular practice. This usage case is very different than anything I've done for the NES though.