nesdev.org

I always have this problem where I don't know if my code is structured properly. Does anybody have advice for code structure?

I'll post my source code after fixing a couple of misleadingly named asm-files, so you could give me some feedback on what I should fix.

I think it being "structured well enough" depends on what it is. There's usually a best way to do things, and that depends on what you're trying to do, so we can't really help you until we see what it is. (And unfortunately, I probably won't really be able to help you because of my moderate lack of experience.)

I just had to change "object.txt" to "plasma grinch.txt"

Well dang, I don't think I'll be able to understand this at all. One reason it's hard to know how your code works is because instead of writing something like
you write:
So you have to meticulously look through the whole thing.

Sometimes I'll use the anonymous labels in ca65 (the : labels), but never for a loop longer than 25 lines. Once the other end of a loop is more than 10 lines away, it's time to think of a name if at all possible.

psycopathicteen wrote:I always have this problem where I don't know if my code is structured properly. Does anybody have advice for code structure?

Trying to read through that code is problematic.

The main issue I'm having is trying to determine the context of the various variables and routines.

For example; timer. I'm guessing (by its location in defines.txt) that its an animation frame timer for the metasprite subsystem, but its name suggests it could also be; a global level timer, an attack cool-down timer, etc.


I would recommend you come up with some system to remove that ambiguity.

I personally prefix all my variables and labels by module/type (ie, EntityPhysics__, z:EntityPhysicsStruct::, etc) which makes it a lot easier to determine the context of the variable. It does mean more typing, but it was the first form of structuring I did with assembly and has been extremely helpful in understanding code past-me wrote.


The second thing I recommend is writing some comments about the parameters/state of each routine. That way you don't have to search through the code to find the JSR that calls it and manually derive the parameters and CPU state. For example:

Espozo wrote:you write: +

So you have to meticulously look through the whole thing.

I personally have no problem with +/- labels and do use them with them with other processors. I'm not using them in my SNES projects because ca65 doesn't fully support them.

Ugh! This looks harder than I thought.

When writing code you'll know what's going on so you can write something that isn't very easy to follow for someone else. But then if a lot of time passes, you might find yourself wondering what is going on when you come back to it.

So you definitely want to be sure that there are either well named functions and variables that no explanation is needed or you should have sufficient comments to explain what is going on in each section with any necessary details. It always helps to have comments written when you write the code to describe what you're doing, how, and why.

I could move the level map and level enemy list into another file, and name it level data.

UnDisbeliever wrote:I personally have no problem with +/- labels and do use them with them with other processors. I'm not using them in my SNES projects because ca65 doesn't fully support them.

Out of curiousity: what do you miss from ca65's implementation of unnamed labels?

Might as well throw in an opinion. I never use +/- labels myself, but they're good for short local branches. Coming up with a unique appropriate name for every label is time consuming and I've gotten used to calling things whatever nonsense pops into my mind first, which results in some real gems like "_BCDScrnotNineCollP2CollCalc". Not terribly useful for telling what's going on. It's also a pain when copying similar pieces of code to meticulously rename everything, when relative labels like +/- would remain correct.

I've introduced a lot of bugs into my code simply by forgetting to change the label on a jump instruction and jumping to the wrong place. I'm actually grateful branches only reach 128 bytes - I catch tons of errors simply because branching to the incorrect label is usually too far away.

As for the rest, all I would suggest is a bit more commenting along the way. I tend to overdo it, to the point where MOST lines of code have a comment next to them, which is probably a bad thing: It's painstaking to ensure my comments remain correct as I edit my code. Sometimes I'm misled because a comment says one thing and the code says another. Still, coming back to a routine months later, I never have to wonder what I was thinking when I wrote it. I try to keep it down to only commenting on things that are not immediately obvious by reading the code itself.

One habit I like is putting a header at the top of each file/subroutine to briefly explain what it does and to keep all the relevant information in one place. For example, I'll list any prerequisites for calling it (must be 16-bit AXY, JoyXRaw must be in register X, etc...), and even reference information so I don't have to keep looking it up (eg/ Tilemap Entries are vhop ppcc cccc cccc).

I also keep my code one indent in from the labels, just because it's easier for me to read that way. Personal preference.

Unless you plan on other people needing to read your source code, I would say it's entirely up to you so long as you'll be able to understand it when you come back later.

The best way to learn about good code structure is to read a lot of code written by other people, and also write a lot of code yourself. You will learn a lot by reading other code.

Writing good code takes experience. I don't think someone can give you tips or tell you how to do it. Telling you how to do it for a specific case is pretty much the same job as writing the code itself. Doing it in the general case requires critical thinking in response to the situation.

Keep working, keep learning, and it will come to you.

I suppose the only way to measure how good your code is, is to work with other peoples' code and compare them to your own?

Comparing it with someone else's code sounds like a good idea. Maybe I can look at somebody's v-blank routine, and compare it with mine.

Well psychopathicteen, I'd be able to compare my code with yours when I've done more, since we seem to be doing the same general thing. You've even used some of the ideas I've came up with, which I'm fine with me because I wouldn't have said them if I wanted them to be secret. You know, how many people are doing stuff for SNESDev? Here's a list of people I can think of:

93143 (Do you know what that number is even from, if anything?)
Espozo (I'm trying, at least)
Khaz (I think?)
Psychopathicteen
Ramsis
Undisbeliever

I think of dforce3000 (N-Warp Daisauksen) and mukunda (Skipp and Friends), actually, when I think of source code.

I have my own v-blank routines, but it's under construction (and currently abandoned). It's functional enough that it can make graphics appear on the screen, but I haven't been able to do a real benchmark yet.