Open Awuwunya opened 2 years ago
cvghivebrain
commented
2 years ago I've been indenting (most) local labels because I thought it helped with readability. It seemed like it made it easier to find where a block of code starts by its label.
You're right about comments looking messy. I wonder if column 64 might be better. Column 80 will leave a pretty large gap in most cases, which could be a problem if someone is using a text editor without current line highlighting.
Awuwunya
commented
2 years ago I've been using column 64 before, but actually it still sometimes found it to be an issue with line length. I am not sure if it's worth the extra large gap but avoiding issues with particularly long lines (unlikely to occur very often, but definitely an issue when it does). If someone is using notepad to edit their code, then maybe the issue with a lack of highlighting is something they just have to learn to deal with =P
also the indenting, while it does help see where a block starts or end, imho it hurts the ability to quickly scan a piece of code. I've been using a lot of local labels (btw, @ is really stupid to write with a Finnish keyboard, so I prefer using . , which is really easy with asm68k to do as well), and what I do to make the blocks easier to tell apart, is using very short local label names, maybe 10 characters or less. Furthermore, its all lowercase with no underscores. it makes it difficult to give a meaningful name but makes it visually distinct.
It's up to you what style you'll prefer, but as someone perfecting a personal style and using it to write a lot of code for years, I think my code style is fairly clean and functional. whether that only applies to me or more people, that's a whole another issue
Brainulator9
commented
2 years ago For my part, I've done (assuming tab size 4): labels at the very start of a line, most instructions on new lines (save for certain constant and equate declarations), one tab for conditional toggles, two tabs for instructions (mostly on different lines than labels, save for certain constant/equate declarations), and any comments one tab after the instruction. Of course, this isn't perfect (jmp/jsr instructions have their alignment thrown off), and based on the OP, I'm clearly doing something wrong. (NB: most editing for me happens on Notepad++, which defaults to 4.)
If anything, I'm concerned over the many, MANY times where tabs are used where spaces make more sense, such as whenever there's a "S U B R O U T I N E" comment. The inverse also happens.
cvghivebrain
commented
2 years ago Having seen what column 80 comments look like now, I don't think it works. It's hard to tell which comment goes with which line, unless I have that line selected. Even at column 64 it's borderline. I'm thinking column 56 would work better. It looks like less than 5% of lines extend that far, in which case the comment could go on a new line if you really want them to be consistent.
Either way, I'll write a program to automatically adjust comments, so don't worry about doing it manually.
cvghivebrain
commented
2 years ago https://github.com/cvghivebrain/68kComment
I've tested it on the main sonic.asm file with column 64, and it looks pretty good.
This is a major issue with hivebrain disassemblies since 2005 - There is a lack of consistency with positioning of elements. I can see this getting worse and worse over time. The generally agreed upon rule is this: 8-wide tabs, instructions at column 16 (though, S2 is at 8 for some reason), instruction arguments at column 24, and comments, at least on S1 disassemblies, at column 40.
However, after looking around a little, there are several problems: labels are not always consistently at column 0 (this seems like a feature, but I think it looks visually messy in most cases - some exceptions with the if macros may be necessary tho), some macros are at column 16, but their arguments are delimited via a single space, rather than any number of tabs, and there is no consistent column. Comments being at column 40 is no good because a lot of instructions are far further - I would actually recommend using column 80. Some instructions, such as dc, also appear in the same line as label, which can further cause usability issues.
I think there should be more standardized rules about columns and lines, to create a better experience for programmers and learners alike, and rules that give the code a very consistent look and usage experience. Right now, there are some good things and some bad things, and some rules clearly broken. This is not great.