• Log inStart now

Code references

We use a variety of formatting to highlight code or other technical language.

When to use code formatting

The following table provides some examples of our use of code format.

For this...

Why use code?


File paths and file names

Using code helps paths and file names stand out, and ensures clarity about the exact file name.

The agent looks for newrelic.config in the %ALLUSERSPROFILE%\New Relic\.NET Agent directory.

NRDB event names and attributes

Many attribute names (such as duration) look like ordinary English words. Formatting them as code helps clarify that we're talking about a specific data point.

To analyze APM errors, use the TransactionError event.

Method names

Using code formatting for method names is standard practice.

To initialize the APM agent, use startAgent().

URLs you don't intend to be clicked

Using code formatting hints to the user that they may need to customize or tweak the URL to ensure it works for them.

In your web browser, navigate to the minion Overview page at http://MINION_IP_ADDRESS.

Command line utility names

If you think a reader or translator might confuse a command with a general English word, use code.

  • curl: Sends http requests via a terminal session–not to be confused with the curls you do with weights at the gym.
  • cat: Lists the first ten lines of a file–not a feline pet who ignores you.
  • date: Displays the day, year, and time–not an outing that couples take.
  • tail: Displays the last ten lines of a file–not the appendage on various mammals.
  • which: Show the location of a program executable–not the pronoun.

To install the utility, use apt.

Inline code formatting

To format inline code (like maxSampleTimes or TransactionError), surround the text with backtick ` characters.

Multi-line code blocks

To format one or more lines of code, insert three backticks ( ``` ) above and below your code. This essentially acts like the HTML <pre> tag.

Highlighting lines of code

To highlight entire lines of code in a code block, you can use lineHighlight= to indicate the specific lines you want highlighted. You do this in the same place where you note the syntax. Here's an example of a code block with the first and third through fifth lines highlighted:

const coolThing = {
key: 'HI',
tada: 'hello'
// this is an important object
// other notes...

Here's what the underlying code looks like for this:

Note that this requires the simultaneous use of syntax highlighting: you must indicate a language if you want to highlight lines.

Placeholders for customer-specific variables

Sometimes we want to use placeholders for variables whose value will depend on the customer or the situation. For example, you might need to use YOUR_ACCOUNT_ID to indicate a placeholder where the customer is meant to input their New Relic account ID.

Some requirements and tips on crafting customer-specific value placeholders:

  • Use all caps and underscores _ to separate words (also known as SCREAMING_SNAKE_CASE).
  • Don't use other elements, like < or >, or $, unless SMEs make a compelling case for why other elements are needed for a specific language or situation.
  • Address the reader directly using YOUR. For example, use YOUR_ACCOUNT_ID and not ACCOUNT_ID.
  • If you think it may be unclear if a component is something of ours or a third party's, you can add NEW_RELIC to the placeholder. For example, when writing about connecting AWS to New Relic, you may want to specific that an account is ours and not AWS's, like this: YOUR_NEW_RELIC_ACCOUNT_ID.
  • Don't combine them with other punctuation to indicate variables (such as wrapping the text in angle brackets or curly braces).

When not to use placeholders

Placeholders are primarily used for when there is a procedure to be done, like a customer who will be running some code. If there's not a procedure involved and a code snippet is being used to demonstrate what something looks like or should look like, you should not use placeholders. Here are some examples of where you should not use placeholders:

  • Example code or files: if you're showing an example config file or another example that isn't directly procedure-related, use example values and not placeholders.
  • API call responses: if you're including the response of an API call that is meant to show what the response will look like and isn't procedure-related, don't use placeholders.

Var tags

Prior to 2023, we used <var> tags to indicate customer-specific variables. Using this breaks syntax highlighting and so we have deprecated those tags.

Copyright © 2023 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.