How do you keep track of what you've coded?

[Shiv0921]

Very entry level question here. I'm making my first AF project and after a long bout of planning I've finally begun coding. But I'm wondering is there a good way you guys keep track of what you have and haven't implemented, considering that AF isn't that easy to just read through?

(or will it become easy to read through once I get more used to it?)

I thought I would tick through the functionality, but there's a lot to be done per function. 

Do you tick off steps on the sequence diagram or something? Or use the # comments for things to come back to? Always build parts in a certain order?

Thinking of my other projects, I just 'know' what's been built, and if I'm unsure I can flick through and have a little read, then if I've missed anything I can pick it up when debugging. (not sure this has been the best approach anyway). 

But with AF it feels a lot more cryptic trying to follow the steps through the project and reread the code, and debugging sounds hard enough that I'd like to minimize it by not missing things in the first place. So I'd like to have a good handle on what's been done and what needs to be done. Is this developed in time, or are there strategies you use? 

Thanks

[Oli_Wachno]

The proper approach: UnitTesting

Pragamtic approach: use bookmarks or have each un-implemented functionality throw an error

[cbutcher]

You may have (some?) luck with breaking your project into smaller parts and using libraries to separate them out.

If you write them in different directories and projects and depend on "installed" versions of the libraries (VIPM, PPLs, etc) then keeping them logically separate can be easier.

Even without building them into packages of some sort, if you develop one section at a time and have a clearly conceptualised API (maybe a list of Messages it can use) you might have an easier time keeping track of how you're doing.

It also makes it easier to test (either with some automated system like JKI VI Tester or Caraya, or just with individual manual test VIs, and then that can help you see what each module/library/blob can do or not do.