Page 1 of 2

Any way to avoid getting stuck in code?

Posted: Wed Mar 29, 2017 7:26 pm
by DementedPurple
My way of programming is just type up whatever comes through my head. And that usually works in the beginning, but once my code starts to become more complicated, I begin to forget what each part of the code is doing, I end up having a whole lot of headers, I forget what jumps where, why it jumps where it does, why it's working with the numbers it's working with, and so on. Is there a way to avoid confusion?

Re: Any way to avoid getting stuck in code?

Posted: Wed Mar 29, 2017 7:35 pm
by tepples
Write pseudocode first to get an idea of what the code should look like.

Re: Any way to avoid getting stuck in code?

Posted: Wed Mar 29, 2017 7:47 pm
by tokumaru
Sounds like you need to comment your code better.

Re: Any way to avoid getting stuck in code?

Posted: Wed Mar 29, 2017 8:21 pm
by psycopathicteen
Print your code on a piece of paper and draw arrows where all the branches are, and see if you can untangle it. Also circle duplicate code you can find, because you can use either a subroutine or macro for it.

Re: Any way to avoid getting stuck in code?

Posted: Wed Mar 29, 2017 9:38 pm
by MottZilla
You should comment your code and structure things in a way that makes sense. In the moment that you are writing code you can be pretty sloppy and get away with it because at the time you know what you are trying to accomplish. Or your goal is small enough that you won't get in trouble being messy. But when you move onto bigger projects you really should think about good structure and comments. Having useful subroutines or dividing tasks into different ones and having comments describing what each function aims to achieve will help.

Re: Any way to avoid getting stuck in code?

Posted: Wed Mar 29, 2017 10:14 pm
by Oziphantom
In the modern era you can name labels and variables with long meaningful things.

Code: Select all

checkCollisionWithTreeParts
;did they hit the tress
	ldx #0
	stx ShotVars.hitTree
_testY
	lda TreeCollRectsY,x ; check top y
	cmp ShotVars.y
	bcs _miss
	lda TreeCollRectsY+1,x ; check bottom y
	cmp ShotVars.y
	bcc _next
	; we are in range of the Y 
	lda TreeCollRectsX,x ; check left side
	cmp ShotVars.x
	bcs _next
	lda TreeCollRectsX+1,x ; check right side
	cmp ShotVars.x
	bcc _next
	#STN ShotVars.hitTree ; record that we hit
	rts
_next
	inx
	inx
	cpx #12
	bne _testY
_miss
	rts
I don't know what assembler you are using so its hard to comment on its abilities but don't use magic numbers, use labels as well. I like to add a 'k' to the front of mine so I know they are a Constant. My assembler (64tass) allows me to make blocks to group them together like so

Code: Select all

kHud .block
	Pointers .block
		HitBirds = kVectors.charBase+(21*40)+16	
		Bullets = kVectors.charBase+(21*40)+4
		RoundNumbers = Bitmap+(19*320)+(6*8)
		RoundNumbersScreen = kVectors.charBase+(19*40)+6
		ShotTextScreen = kVectors.charBase+(22*40)+4
		BirdsNeededScreen = kVectors.charBase+(22*40)+16
	.bend

	Colours .block
		BirdNotShot = $10
		BirdFlash = $00
		BirdShot = $20
		BulletShot = $00
		Bullet = $F0
		Sky = $03 ; cyan
		FlyAwaySky = 10 ; pink
		RoundNumber = $50
		RoundEmpty = $99
		ShotTextNormal = Sky<<4
		ShotTextFlyAway = FlyAwaySky<<4
	.bend
	
	Values .block
		NumBirds = 10
		NumBullets = 3
	.bend
.bend
And then in code I can do

Code: Select all

lda #kHud.Colours.Sky
sta SkyColour
So the comments basically write themselves.

Re: Any way to avoid getting stuck in code?

Posted: Wed Mar 29, 2017 10:21 pm
by tokumaru
Also, be consistent in your choices. Try to solve similar problems using similar solutions, so it's easier for you to recognize programming patterns later. For example, when simulating high-level constructs like IF, FOR, WHILE, etc., try to follow the same conventions every time, so you can easily recognize these blocks in the future instead of spending time trying to make sense of what appears to be spaghetti code.

Like I said before, comment the hell out of your code. I don't mean pointless comments like "load A with 32" or "clear the carry" every freaking line for things that are obvious from the instructions themselves, but general descriptions of what each block of code is doing.

Code: Select all

	;fill MyArray with the first 8 multiples of 16
	ldx #$07
	lda #$70
	sec
Loop:
	sta MyArray, x
	sbc #$10
	dex
	bpl Loop
Everything I do is organized in blocks like this, that I separate by complexity and purpose, and each block has a comment describing what it does.

I also greatly dislike huge source files that I have to scroll through to find a piece of code, so I always put each subroutine, interrupt handler, table, etc. in its own file, and have the main file include all the files in the appropriate order. Each of these files has a header, detailing what it contains. Subroutines have explanations about input parameters, return values, and registers/variables that are modified.

Re: Any way to avoid getting stuck in code?

Posted: Thu Apr 20, 2017 2:52 am
by Garth
Very good advice above. I would comment that no matter how experienced you are, it is easy to lose control of a project if you don't always try, even from the beginning, to always be more structured, more neat, improve your commenting, etc..

I've been a macro junkie since about 1986 or '87. Macros can do a lot to make your source code more concise. In my assembly-language programming, I had wanted to use program structures from higher-level languages for years, but figured out how to do it only a few years ago using macros. It made things so much easier, and made assembly language so much more of a pleasure!! The majority of labels are gone, and the spaghetti is gone. I wrote it up in a section of my website, at http://wilsonminesco.com/StructureMacros/ . It starts with the basics of what macros are and how to use them, before getting into the structure macros themselves. People often think macros will be very inefficient; but in most cases, the macro will assemble exactly the same machine code you would have gotten without them, except that their usage will reduce bugs, and may also actually help you write more-efficient code. This is because you can see what you're doing better.

Re: Any way to avoid getting stuck in code?

Posted: Thu Apr 20, 2017 7:34 am
by Sumez
psycopathicteen wrote:Print your code on a piece of paper and draw arrows where all the branches are, and see if you can untangle it. Also circle duplicate code you can find, because you can use either a subroutine or macro for it.
Image

Also don't forget to wrote "TODO"-comments everywhere you're writing sloppy routines that need to be tightened up later. :P

Seriously though, even though it sounds simple, Oziphantom's suggestion should be taken seriously. I still see "old school" programmers sticking to confusing abbreviations and short names for variables and labels. That stuff just isn't necessary. Especially for compiler/assembler stuff that's not even going to affect your eventual build.

Another way I've found to make my own code more manageable is using a lot of macros with similarly easily understandable names. Even when I'm only including the macro in one place, it makes the code for that specific area/routine much more easy to read when I return to it later, effectually breaking my code up into manageable bits without the overhead caused by subroutines.

Re: Any way to avoid getting stuck in code?

Posted: Thu Apr 20, 2017 9:16 am
by Dwedit
Sometimes you can write the comments, then write the code afterwards.

Re: Any way to avoid getting stuck in code?

Posted: Thu Apr 20, 2017 9:29 am
by tokumaru
My source files have tons of "TODO" comments I can easily search for, as I often rush through the boring parts to get to the interesting stuff quicker! I try to make the sloppy stuff as obvious as possible, so that there's absolutely no chance of me forgetting​ to change it later.

Re: Any way to avoid getting stuck in code?

Posted: Thu Apr 20, 2017 9:39 am
by tepples
Until you just throw your hands up in frustration:

Code: Select all

; TODO: tudo
Or if you lived in another South American country, the joke would be even easier:

Code: Select all

; TODO: todo

Re: Any way to avoid getting stuck in code?

Posted: Thu Apr 20, 2017 10:04 am
by Sumez
tokumaru wrote:My source files have tons of "TODO" comments I can easily search for, as I often rush through the boring parts to get to the interesting stuff quicker! I try to make the sloppy stuff as obvious as possible, so that there's absolutely no chance of me forgetting​ to change it later.
I'm glad I'm not the only one with this habit. :P
At work though, we do have a guideline that says no "TODO" comments or similar should make it through code review, and it's been working out exceptionally well. The more you focus on your goals (which you should), the more likely you are to forget about technical debt (which you shouldn't).
If I had to give a serious estimate I would assume it's unlikely that more than 30% of the "TODO" lines in my current NES project will ever get the attention they should. Of course, it's all a question of premature optimization and profiling. Priorities.

Re: Any way to avoid getting stuck in code?

Posted: Thu Apr 20, 2017 10:36 am
by tokumaru
tepples wrote:

Code: Select all

; TODO: tudo
Yup, it happens!
Or if you lived in another South American country, the joke would be even easier:

Code: Select all

; TODO: todo
That kinda still works in portuguese too, as "todo" means "all" or "whole". But yeah, "tudo" ("everything")works better in a to do list.

Re: Any way to avoid getting stuck in code?

Posted: Fri Apr 21, 2017 7:39 am
by psycopathicteen
Sumez wrote:
psycopathicteen wrote:Print your code on a piece of paper and draw arrows where all the branches are, and see if you can untangle it. Also circle duplicate code you can find, because you can use either a subroutine or macro for it.
Image

Also don't forget to wrote "TODO"-comments everywhere you're writing sloppy routines that need to be tightened up later. :P

Seriously though, even though it sounds simple, Oziphantom's suggestion should be taken seriously. I still see "old school" programmers sticking to confusing abbreviations and short names for variables and labels. That stuff just isn't necessary. Especially for compiler/assembler stuff that's not even going to affect your eventual build.

Another way I've found to make my own code more manageable is using a lot of macros with similarly easily understandable names. Even when I'm only including the macro in one place, it makes the code for that specific area/routine much more easy to read when I return to it later, effectually breaking my code up into manageable bits without the overhead caused by subroutines.
That's either Billy from Power Rangers finding where the Zeo Crystals are, or Glen Beck finding the Illuminati headquarters.