Author Guidelines

               

• Use the following formats:

            Title: Arial, 16 Bold

            Subheading: Arial, 13, Bold

            Body: Arial, 10

            Code: Courier New, 10

• Include a title, byline, identify the demo file (if included), and an email address. See any of the online articles for an example.
• Send a short bio with your first article.
• Don’t embed figures in the document. Instead, send figure files separately. We’ll link them later.
• Submit all pieces—the document, figures, and example files in one zip file.
• Don’t use two space characters between sentences—just one space character. The two space rules applies to correspondence, not published articles.
• Please use the m-dash character, instead of two hyphens. To insert an m-dash (—) press Ctrl + Alt + - (the minus key in the numerical keypad; the minus/underscore key won’t produce an m-dash).
• Please introduce code with some kind of brief explanation—code should always follow an introduction.
• Using personal pronouns is permissible, but we don’t recommend them. Starting every sentence with “I wanted to …” or even, “Next, I decided…” should be avoided.
• Feel free to use informal speech, especially contractions: it’s, that’s, they’re, and so on.
• The contraction “it isn’t” is preferable to “it’s not.” Charlotte will be collecting fees from offenders. J
• Remember that the possessive form of it, isn’t it’s, but its.
• Don’t use quotation marks to separate normal terms, functions, or the names of dialog boxes, and so on, from the rest of the text. A good rule of thumb is to use quotation marks only when trying to separate the text. For instance, consider the following sentence: Now, enter the text value “abc.” In this case, you might want to use the quotation marks to make sure the reader recognizes that the string “abc” is the string in question.
• Use italics sparingly for emphasis.
• Don’t use bold for emphasis.
• Spell out the numbers one through ten, unless specifying the value as a numeric character is required. All others can be represented by numeric values.
• Don’t start sentences with a value if at all possible. Preface the value with “The value…” or some other modifier.
• Use “for example,” instead of “e.g.”
• The word is Okay is Okay. The abbreviated form, OK, isn’t Okay, unless you’re talking about an OK button.
• Use your own naming and formatting conventions for code, but please be consistent. There’s no need to comment code snippets, but by all means do so if that’s your habit. We’ll do a bit for you in text, but we won’t touch your code.
• Use standard property naming conventions only when actually referring to the property. For instance, “…when the RowSource is ….” should be “… when the row source (or data source) is …” However, if referring to the property, please use the property’s proper name.
• The programming language, SQL, uses all uppercase letters.
• When referring to Boolean values, use True and False (proper case). When speaking generically, use lower case. If in doubt, use lower case.

Here’s what you can expect from us:

The guidelines posted above aren’t meant to limit you in any way. All articles, tips, and suggestions are always welcome. But if you’re inclined, authors can save volunteer hours by trying to apply our guidelines to their work.

The editing process can take a long time. After submitting an article, you may not hear from us for a while. At some point, an editor may contact you with questions about your article. Please respond quickly if this happens. When we think your article is ready for publication, we’ll send you an edited version for your review. Carefully read the article, word for word. We want to ensure the technical integrity of your article, so please don’t take anything for granted—we make mistakes! Discuss any discrepancies with the editor. In addition, please do your best to attend to all problems in one E-mail. Several E-mails with “Oh, I found one more….” create a lot of unnecessary work for the volunteers. We will remain flexible, but your close scrutiny helps.

Once an article is published, you may receive questions from readers. Any response is strictly voluntary.

If, at some point, you find an error in your article, please notify us by E-mail with a correction.

Suggestions are always welcome.