Update Sets

Update sets should be named using the following standard:
SNG - [Ticket# or description] - v.[#]

If we have a ticket number corresponding to a ticket in the customer's instance, use that. e.g.:
SNG - INC001234 - v.1

If we have a ticket number, please include a description of the issue in the Description field of the update set.

Understand what is, and is not captured in an update set. Check your update set occasionally, to ensure that all of your changes are being captured.

If you need to make a change that is unrelated to the task (such as adding a related list to a form view), do so in the Default update set, and then switch back to your task update set.

Never re-open an update set after it's been closed. Instead, if you need to make changes related to the same issue/task, create a new one and increment the version number at the end. e.g.:
SNG - INC001234 - v.2

Remember that the update set picker can lie. If you change your update set in one tab, then flip over to another tab, that other tab will show the wrong update set. Before making major changes, if you're not certain what update set you're in, click the "Refresh" icon in the System Settings > Developer tab, next to Update Set. Click it a few times... it takes a few seconds, and sometimes takes multiple clicks.

Code

JSDoc

JSDoc is a standardized way to document your code. You can read all about it over at usejsdoc.org; specifically, the "Block tags" section.
Examples of JSDoc-Documentation most relevant to us, can be found at the ES2015 class documentation examples page.
As a minimum, you want to document every public function in your code, especially in your Script Includes.

Here's a (slightly excessive) example:

/**
* @description - picklePickles pickles a pickle and returns that pickled pickle, with or without dill, based on the specified argument.  
* @param {boolean} [dill=false] - This optional argument determines whether or not to add dill during the pickling process. The default value for this parameter is false. Aside from the fact that a default value is specified, you can tell that it's optional because it is in [square brackets].   
* @returns {Cucumber} - The pickled cucumber.
*/
function picklePickles(dill) {
//An instance of the {@link Cucumber} class, which will be altered in-place and eventually returned, pickled.
var coocumbur = new Cucumber();
if (dill == undefined) {
dill = false;
}
if (dill) {
    coocumbur.addFlavah('dill');
}
coocumbur.pickle(true);
/*
Set 'ajar' to false. When setting to false, ajar requires a second argument: the vessel.
For this, we pass 'jar', because we're placing the pickle into a jar.
*/
coocumbur.ajar('false', 'jar');
return coocumbur;
}

Asynchronicity

ALL client-side code that requests data from the server should be executed asynchronously. The only exception to this rule, is onSubmit scripts, which must execute synchronously in order to prevent the browser from leaving the page before the callback function can be executed.

If you know what you're going to need and whether you're going to need it before the form even loads a record, a Display business rule is the best and most efficient way to retrieve that data and present it to the client, using the g_scratchpad object, which is basically just a place where you can store properties containing useful data retrieved from the server.

GlideAjax is generally the preferred method, over another asynchronous method like gr.query(function(gr) {/*Code here*/}), or g_form.getReference('ref_field_name', function(gr) {/*Code here*/});. This is because GlideAjax can be made to return ONLY the single value that you need, for example, from a GlideRecord (rather than the entirety of the contents of the record). However, using getReference() is quite a lot easier, and nobody will blame you for using it unless it's on a table with 1,400 columns.

We have an excellent article on GlideRecord, GlideAjax, and general asynchronicity, over at this link. Please read it, especially if you're not super familiar with GlideAjax!

Documentation

This section is referring to non-code documentation.

As you work, as you try different solutions, and when you find one that works, you should be writing documentation in the notes section of the Trello card corresponding to that task.

Here is an example of good work notes:
-Disabled inbound email action "Create Incident (new)".
-Re-processed an existing inbound email.
-A different inbound action was triggered: "Create Incident"
-Disabled that action as well.
-Re-processed the same email
-No actions triggered.
-Tested several more emails. No issues. Closing update set.