Suggestions on formatting of code

[utz]

So no-one indenting for loops, conditional code etc ???

it is not even always possible, considering that jumps can create a fine web. it is much easier (and cleaner, i believe) to split the code to "logical blocks" with empty lines.

Exactly, it's not always possible/useful to apply best formatting practises from higher level languages to assembly.

I have a habit of always putting an empty line after jp/jr/call/ret. I also agree with ketmar that blank lines are a good way of separating logical blocks of code. Multiple lines and/or decorated comments for larger units, aka

Code: Select all

; --------------------------------------
; A new section starts here
; --------------------------------------

Also I generally don't put labels on the same line as code, but that's more down to personal preference, I guess.

[kolbeck]

Thank you @Ast A. Moore,

I currently just use notepad, but use VS Code for other stuff, so will see if that has some of the functionality you mention. VS Code is good because it runs on both Windows and Linux.

I use VS code with a z80 formatter/highlighter found on marketplace- works great on Mac as well.

[Cosmium]

I know it doesn't make a jot of difference to the assembler, but it's interesting how some of you are using uppercase, and others lowercase.... Just be consistent I suppose is the answer.

I always use uppercase for the Z80 instructions. Just seems to make them immediately stand out against the rest of the test. That and it's a habit from the past!

[Ast A. Moore]

I know it doesn't make a jot of difference to the assembler, but it's interesting how some of you are using uppercase, and others lowercase.... Just be consistent I suppose is the answer.

To me, lowercasing the instructions has always looked neater. Not as SCREAMY AND SHOUTY as using all uppercase. Oh, and it’s too much extra work to hold down the Shift key.

[Einar Saukas]

To me, lowercasing the instructions has always looked neater. Not as SCREAMY AND SHOUTY as using all uppercase. Oh, and it’s too much extra work to hold down the Shift key.

Next time try using CAPS LOCK


EDIT: Jokes aside, I personally think lowercase mnemonics are more legible too.

[Ast A. Moore]

To me, lowercasing the instructions has always looked neater. Not as SCREAMY AND SHOUTY as using all uppercase. Oh, and it’s too much extra work to hold down the Shift key.

Next time try using CAPS LOCK

Funny you should mention the Caps Lock key. I have it disabled system-wide.

[utz]

What a waste. That key should be remapped as a second Ctrl key, of course

[Joefish]

I use CAPS for constant values I've defined at the top of a file. Everything else is lower case.

I sometimes extra-indent loops, or the bits between PUSH and POP of data, to help keep track of it.

I also include a file of macros that defines things like SCREEN EQU 16384, and also JPEQ, JPGE and JPLT to use instead of jp nz, jp nc or jp c following a 'compare' as I can never remember which way round to use the last two. It's then a reminder that there's no way to do JPGT or JPLE with a single operation.

Also define stuff like WAIT_VBL as EI followed by HALT.

[Morkin]

Also define stuff like WAIT_VBL as EI followed by HALT.

...Isn't that more keystrokes?

[Ast A. Moore]

as I can never remember which way round to use the last two.

I’m in the same club.

[Joefish]

Also define stuff like WAIT_VBL as EI followed by HALT.

...Isn't that more keystrokes?

Yes, by one, but it's also an easy way to remember to do an EI before a HALT where your design needs it so you don't deliberately hang your own code.

[Cosmium]

I also include a file of macros that defines things like SCREEN EQU 16384, and also JPEQ, JPGE and JPLT to use instead of jp nz, jp nc or jp c following a 'compare' as I can never remember which way round to use the last two.

That's a bit like the perpetually cryptic (to me at least!) RRCA and RRA etc. I can never can remember which one does what with the carry and always have to look it up. Maybe some macros to clearly differentiate these would be helpful to?

[Einar Saukas]

That's a bit like the perpetually cryptic (to me at least!) RRCA and RRA etc. I can never can remember which one does what with the carry and always have to look it up.

I could never remember it either, that's one of the reasons I did this:

https://www.ime.usp.br/~einar/z80table/index.html

Click on "MISC" at the bottom of that page.

[ketmar]

as we started talking about remembering commands... i'm often looking into Zymosis code to remember details on some instructions. there cannot be a better reference than a working Z80 emulator! ;-)

[Joefish]

Good point. I might add RR8 and RR9 to my macros file to remember how many bits are used, as I think RR and RRC are defined the wrong way round.

[Ast A. Moore]

. . . to say nothing of the logical and arithmetic shifts.

[utz]

A round of appreciation for Einar's z80table! Opening that up is pretty much always my first action when doing any serious Z80 coding.

[Ast A. Moore]

I use a copy an offline copy of this. I made a few corrections to it.

[XoRRoX]

Nice to see everyone's approach.

I'm putting labels on a separate line to be more flexible with using descriptive names.

Code: Select all

	call clearPlayArea

announceLvl2:
	xor a
	ld (flagSkipSegment),a

[Morkin]

Nice to see everyone's approach.

I'm putting labels on a separate line to be more flexible with using descriptive names.

Code: Select all

	call clearPlayArea

announceLvl2:
	xor a
	ld (flagSkipSegment),a

My preference has been for camelCase, just easier on my eyes.

...So just out of interest (for someone who doesn't do a lot of 'modern' development), what is it about camel case that you like/prefer?

Or is it a habit thing that's been learned (e.g. Javascript)?

[Einar Saukas]

Good point. I might add RR8 and RR9 to my macros file to remember how many bits are used, as I think RR and RRC are defined the wrong way round.

RRC means "Rotate Right Circular".

A bad name choice indeed.

[andydansby]

Nice to see everyone's approach.

I'm putting labels on a separate line to be more flexible with using descriptive names.

Code: Select all

	call clearPlayArea

announceLvl2:
	xor a
	ld (flagSkipSegment),a

My preference has been for camelCase, just easier on my eyes.

...So just out of interest (for someone who doesn't do a lot of 'modern' development), what is it about camel case that you like/prefer?

Or is it a habit thing that's been learned (e.g. Javascript)?

For me it comes to when I write multi-word long variable names. If you had a choice between myvariablename or my_variable_name vs myVariableName, I can read the camel case much easier. It became more of a habit after studying other people’s C code and influenced me.

[XoRRoX]

...So just out of interest (for someone who doesn't do a lot of 'modern' development), what is it about camel case that you like/prefer?

Or is it a habit thing that's been learned (e.g. Javascript)?

Same reason as Andy wrote. It visually breaks up multi-word expressions where one cannot use spaces without having to type underscores, which also makes them longer; waitForAnyKey, showBossDefeated.

I started doing that from the very beginning in my coding adventures way back in Turbo Pascal.

To let them start with a lowercase character is just something I saw recently in someone else's code and for some reason thought looked cool

[Bedazzle]

I know it doesn't make a jot of difference to the assembler, but it's interesting how some of you are using uppercase, and others lowercase.... Just be consistent I suppose is the answer.

CONSTANTS
IFDEF
MACRO
labels
code

[Bedazzle]

So no-one indenting for loops, conditional code etc ???

I do empty line after djnz, jr or jp

One call (or even several call's) is surrounded by empty line before and after.