<code> Code

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

Usage/Remarks

The <code> element may contain preformatted text, which may contain 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 dialog, 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; a 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

Base Attributes

Miscellaneous non-JATS-specific Attributes

xml:space (fixed value = preserve)
Models and Context
May be contained in
Description
Content Model
<!ELEMENT  code         (#PCDATA %code-elements;)*                   >
Expanded Content Model
(#PCDATA | email | ext-link | uri | bold | fixed-case | italic | monospace |
overline | roman | sans-serif | sc | strike | underline | ruby | inline-graphic | inline-media |
private-char | abbrev | index-term | index-term-range-end | named-content | styled-content | fn |
target | xref | sub | sup)*
Tagged Samples
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 and 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>
...
XML document fragment
...
<p>An example XML WorkOrder element is shown as follows:
  <code 
   code-type="xml" 
   language-version="1.1"
   xml:space="preserve" 
   orientation="portrait"
   position="anchor" >
   ...
  &lt;WorkOrder ID="P7710">
   &lt;WorkItem name="Testing">
    &lt;Datum xsi:type="string" value="A123">
   &lt;/WorkItem>
  &lt;/WorkOrder>
   ...
 </code></p>
...
XSD Schema fragment
...
<p>As of the release of this standard, the schema described 
 incorporates the following &ldquo;header&rdquo; 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">
   &lt;xs:import namespace="urn:IEEE-1671:2008.01:Common"
     schemaLocation="Common.xsd"/>
  &lt;/xs:schema>
 </code></p>
...
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 before the earliest days of SGML 
development. Our initial tree structure was very simple:
 <code code-type="dtd">
  &lt;!ELEMENT  implications  (tree+) >
  &lt;!ELEMENT  tree          (root, branches) >
  &lt;!ELEMENT  root          (term, synonym?) >
  &lt;!ELEMENT  branches      (term | (term, synonym) | tree)* >
</code>
</p>
...
XSLT stylesheet fragment
...
<p>Literal result elements are very convenient:
 <code code-type="xml" language="xslt">
  &lt;xsl:template match="sec/sec/title" priority="2">
    &lt;h2>
      &lt;xsl:apply-templates/>
    &lt;/h2>
  &lt;/xsl:template>
 </code>
</p>
...