Transcription

Hi, Matt from AppWorks and today we’re going to be talking about best practices and specifically commenting code, so what is the best practice? So when I did a quick search on Google, it defines it as a set of proven approaches that, when you use them in combination, really strike at the root of problems, and prevent problems. So that’s a really good way to think about it. So they are generally accepted, but there’s probably going to be some debate. 

Let’s take a look at a FileMaker database. This is a version of a database that we use for our training classes, and it started out as a sample file from FileMaker and if we take a look at the script workspace, which is the main place you’re going to be commenting, notice that in FileMaker, the sample files, there’s actually not any comments in the code, so that’s not a good practice. Here’s a script that I have that talks about what we generally do for basic scripting in the database that’s going to be used by several people, or even just by you.

First of all, I like to always put a date in when I started, and I generally put a date in any change that I make, and I put my initials or name or something, so I can track exactly what it is. Mostly this is for when I go back – I can see “oh! I remember when I made that change” or sometimes you’ll see a problem you reported, like, “oh, on a certain day, last Tuesday, all of a sudden when we started making invoices, this other thing stopped working” and you can go back in the code and see “oh, yes, look on Monday I made this change, and it inadvertently, you know, while fixing one problem, it inadvertently caused another one.” So putting a date and time in, or just date in, on your comments, is a really good idea.

The other thing that I sometimes do is I pretty much always do, when I’m changing context, because context is king in FileMaker. When you use a go to layout command or anything that changes to a different context, it’s a really good idea to put a comment there, because, as you’re debugging the script and looking at it, that’s a very important line of code. Also when I have really important things that happen, like a find or a delete or something like that, I’ll sometimes put just little comment lines above and below it with some character like a = or asterisk or something like that.

Ok, so what if you have, I’m really really serious about commenting, so for example, we have a free commercial system called fmLog, and in fmLog we have a lot of comments here. So really more comments than actual code in this case gives you a version history, gives you samples of what you can copy and paste, you can just click on copy and paste. A good thing to try here is if there’s dependencies, you know, what is dependent on this script? And what is this script dependent upon? Input and output, required parameters, and then like a change like we talked about before, a change log of notes.

So those are the things that I would submit are best practices for the different cases of FileMaker scripting. We haven’t really talked about scripting inside of code, but if you’re doing like a set variable or something like that, when you have some code here, I think it’s a really good idea to also put comments here, so for example, if you’re doing a case statement, and you’re looking for if 1 = 2, you can put comments here by putting // after it. Also, very important when you’re writing, to spell things correctly even though there’s no spellcheck at all for commenting code. So that’s another area that we frequently comment, is inside code itself. Thanks very much for your time.