<code>

Code

A container element for technical content such as programming language code, pseudo-code, schemas, or a markup fragment.

Remarks

The <code> element may contain preformatted text, containing emphasis elements for syntax coloring, or it may contain an external link to a binary executable file.
Best Attribute Practice: The various semantic attributes should be used to name the type of code, the language, the intended platform(s), etc. Executable code should always be marked as such using the @executable attribute. The @specific-use attribute may also be used to describe the rationale or uses for a code sample.
Alternatives: When code is present in more than one form, the <code> element can be used inside an <alternatives> element. The various versions of the code can be syntax colored using the face markup from this Tag Set, syntax colored using processing instructions or other mechanisms from a syntax coloring program, plain ASCII for cut and paste, an executable version, etc.
MathML: The MathML elements to describe equations are not permitted within <code>. If equations are encountered within computer code, they can be tagged using the element <named-content> to preserve the fact that they were equations or the element <styled-content> to preserve the fact that they were set in a math font.

Related Elements

This element is similar to <preformat> in the preservation of whitespace, line-endings, and such formatting. The <code> element differs from <preformat> semantically; a <preformat> element may contain almost anything, for example, ASCII art, a man-machine dialogue, error messages, 3 words on a line with space between them, or a poem. The <code> element is specifically for technical coding fragments, for example: computer programming language code; executable binary code; illustrative pseudo-code; an XSD, RNG or DTD schema fragment; an SQL or XQuery query; or a markup fragment that is part of an XML document instance.
Historical Note: Previous versions of this Tag Set have used the <preformat> element with an attribute @preformat-type="code" to express the semantic material that will hereafter be tagged as <code>.

Attributes

Expanded Content Model

(#PCDATA | email | ext-link | uri | bold | fixed-case | italic | monospace | overline | overline-start | overline-end | roman | sans-serif | sc | serif | strike | underline | underline-start | underline-end | ruby | abbrev | index-term | index-term-range-end | milestone-end | milestone-start | named-content | styled-content | fn | target | xref | sub | sup)*

Description

This element may be contained in:

Example 1

A C++ code fragment:
...
<p>So, to make a simple button:
<code   
  code-type="user interface control" 
  language="C++"
  language-version="11"
  xml:space="preserve" 
  orientation="portrait"
  position="anchor">
#include &lt;conio.h>
#include&lt;win_mous.cpp>
// Needed for mouse &amp; win functions#define
OK (x>=170 &amp;&amp; x&lt;=210 &amp;&amp; y>=290 &amp;&amp; y&lt;=310)

#define
CANCEL (x>=280 &amp;&amp; x&lt;=330 &amp;&amp; y>=290 &amp;&amp; y&lt;=310)

#define PUSHME (x>=170 &amp;&amp; x&lt;=330 &amp;&amp; y>=150 &amp;&amp; y&lt;=250)
</code>
</p>
...

Example 2

Part of an XML document:
...
<p>The XML WorkOrder should look as follows:
<code 
   code-type="xml" 
   language-version="1.0"
   xml:space="preserve" 
   orientation="portrait"
   position="anchor">
...
&lt;WorkOrder ID=”P7710”&gt;
  &lt;WorkItem name=”Testing”&gt;
    &lt;Datum xsi:type=”string” value=”A123”/&gt;
  &lt;/WorkItem&gt;
&lt;/WorkOrder&gt;
...
</code>
</p>
...

Example 3

Part of an XSD Schema:
...
<p>As of the release of this standard, the schema described 
incorporates the following “header” information:
<code 
  code-type="xml"
  language="xsd"
  language-version="1.1" 
  xml:space="preserve" 
  orientation="portrait"
  position="anchor">
&lt;xs:schema 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:c="urn:IEEE-1671:2008.01:Common"
    xmlns="urn:IEEE-1636.1:2008.01:TestResults"
    targetNamespace="urn:IEEE-1636.1:2008.01:TestResults"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified"
    version="2.01"&gt;
  &lt;xs:import namespace="urn:IEEE-1671:2008.01:Common"
    schemaLocation="Common.xsd"/&gt;
&lt;/xs:schema&gt;
</code>
</p>
...

Example 4

A DTD fragment:
...  
<p>Trees, of course, are hardly a random choice for our
methodology. ... Hierarchical trees have been understood as a
way of viewing document structures since the earliest days of
SGML development. Our initial tree structure was very simple:
<code code-type="dtd">
&lt;!ELEMENT  implications  (tree+) &gt;
&lt;!ELEMENT  tree          (root, branches) &gt;
&lt;!ELEMENT  root          (term, synonym?) &gt;
&lt;!ELEMENT  branches      (term | (term, synonym) | tree)* &gt;
</code>
Terms are the literal strings for which the Ferret engine searches; they
are the most specific expressions to be found in real documents of the
concepts on which classifications rules act.</p>  
...

Example 5

A fragment of an XSLT stylesheet:
...  
<p>As you can see in the following excerpt, use of literal
result elements is very convenient:
<code code-type="xml" language="xslt">
&lt;xsl:template match="div/divhead" priority="2"&gt;
  &lt;<named-content content-type="literal result">h2</named-content>&gt;
    &lt;xsl:apply-templates/&gt;
  &lt;<named-content content-type="literal result">/h2</named-content>&gt;
&lt;/xsl:template&gt;
</code>
</p>
...