Thisguideline is a part of the English Wikipedia'sManual of Style. Editors should generally follow it, thoughexceptions may apply.Substantive edits to this page should reflectconsensus. When in doubt, discuss first onthis guideline's talk page.

Shortcuts MOS:CSMOS:CS MOS:COMPSCIMOS:COMPSCI

This manual contains some suggestions which aim to contribute towards writing clear, pleasant looking, and hopefully interestingcomputer science articles. This guide is a complement to the generalManual of Style.

Probably the hardest part of writing any technical article is the difficulty of addressing the level of technical knowledge on the part of the reader. A general approach is to start simple, and then move toward more formal and technical statements as the article proceeds. The following structure is merely recommended; editorial discretion and consensus might find an alternative structure more appropriate for some subjects.

The article should start with anlead section of length appropriate to the article content, which describes the subject in general terms and properly summarizes the article. This opening material should give the casual reader a quick understanding of the concept. Name the field(s) of computer science this concept belongs to and describe the context in which the term is used.Write thearticle title and any alternative names in bold. Include the historical motivation, provide some names and dates, etc. Here is an example:

It is a good idea to begin the main part of the article with an informal introduction, commonly titled "Background" though "Overview" has also been used, that gives the non-technical reader a basic understanding of the fundamental concepts of the topic being presented. If the concept in question is somewhat theoretical, it is helpful to describe itspurpose orapplied use(s) toward the top of the article, either concisely in the lead section or in a post-lead introductory section. It is also useful to have some representativeexamples, which could serve both to expand on the concept in question and to provide some context as towhy one might want to use that concept.

A picture is a great way of bringing a point home, and often it could even precede the technical discussion of a concept.WP:How to create graphs for Wikipedia articles has some hints on how to create graphs and other pictures, and how to include them in articles.

If not included in the introductory material, a section about thehistory of the concept is often useful and can provide additional insight. This often forms its own "History" section.

Computer science is a broad field which encompasses a number of different kinds of ideas. The structure of the main part of an article will vary with the type of article. Here are some general guidelines for structuring a few different classes of computer science articles. Where possible, these guidelines include one or two examples of a "good" article,i.e. an article demonstrates the style we're aiming for in that particular class of article. Always keep in mind that these areguidelines, not hard-and-fast rules: some articles will need to deviate from this structure; some articles will be hard to classify; some won't fit into these classifications at all. Use common sense in applying these guidelines.

An article on an algorithm should generally consist of:

1. A description of the algorithm (including pseudocode)
2. A formal discussion of the algorithm's time and space complexity
3. A discussion of any implementation and performance issues

A good example isbinary search algorithm, afeatured article.

An article on a data structure should consist of:

1. A description of the structure, and any operations that can be performed on the structure
2. An overview of the applications for the structure in question
3. A discussion of any implementation and performance issues

An article describing a classic problem should generally consist of:

1. A statement of the problem.
2. A discussion of the relevance of the problem.
3. A discussion of the history of the problem if notable.
4. A description of solutions to the problem if any exist.

An example is thedining philosophers problem.

The structure of an article describing asoftware design pattern or otherdesign pattern in computer science (includingcreational patterns,structural patterns,behavioral patterns, andconcurrency patterns) should draw on industry best-practice models provided by reliable sources on the subject. Some of these include:

• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the "Gang of Four" or GoT; 1994, Addison-Wesley / O'Reilly). Our article on the book atDesign Patterns § Patterns by type links to a number of such design-pattern articles.
• Design Patterns for Object-Oriented Software Development by Wolfgang Pree (1995, Addison-Wesley)
• Various works on design patterns for specific languages and other applications are available for free reading via the Internet Archive Open Library[1], and a variety of others are hosted on free websites.

An article describing a field of study within computer science should include:

1. A brief overview of the history of the field
2. A basic introduction to the key concepts around which the field revolves
3. A description of the important principles, theorems, or results produced by the field
4. A discussion of relationships with other fields of study (inside and outside CS)
5. Some pointers to articles that describe particular aspects of the field in greater detail

An article describing some kind of formalism should contain:

1. A brief outline of the history of the formalism (originator, major developments, etc.)
2. An informal introduction to the basic concepts involved (preferably including some simple examples)
3. A formal definition
4. Discussion of important applications or implementations
5. Description of major tools that support the formalism
6. Brief overview of related or derived formalisms

A good example islambda calculus.

An article describing a programming construct should generally include:

1. A brief overview of what the construct is, and how it is used (perhaps including an informaloperational semantics)
2. A listing of alternative names for the construct
3. Pseudocode or a small code sample demonstrating the construct in use
4. Description of any equivalences between the construct and other constructs
5. A discussion of any variations in the semantics of the construct
6. A discussion of any disadvantages to use of the construct

Examples includecontinuation,closure (computer programming), andexception handling.

An article describing a programming language should generally include at least:

1. A brief outline of the history of the language
2. An overview of the language features
   • Programming paradigm(s) that the languagesupports, andhow well it supports them
   • Style of type-checking, support for design by contract or other specification techniques
   • Memory management style
3. A basic introduction to the language syntax (including some code samples)
4. An overview of the formal semantics of the language (if one exists)
5. A list of available implementations and supported platforms

A good example is theRust (programming language) article.

An article describing theorems or conjectures should generally contain at least:

1. A brief informal description of the theorem or conjecture.
2. A formal statement of the theorem or conjecture.
3. A discussion of the history of the theorem or conjecture.
4. A discussion of impacts, consequences, or implications of the theorem or conjecture.

As many computer science theorems and conjectures are often stated informally in popular literature it may also be beneficial to provide some discussion of common misconceptions or misinterpretations of the theorem or conjecture.

The names of such thingsare not capitalized except where they contain a proper name (e.g. a surname).

Good examples includehalting problem andChurch–Turing thesis.

An article describing a class of tools should generally contain:

1. A brief overview of the purpose of the tool
2. A brief history of the development of the class of tool
3. Discussion of any major subclasses of the tool class
4. Brief description of the key underlying algorithms or implementation techniques

Examples includecompiler,text editor, andautomated theorem proving.

SeeWP:Manual of Style/Layout § Standard appendices and footers for use of "See also", "Notes", "References", "External links" sections, and navigation templates.

• WP:Manual of Style/Mathematics has some good advice on how to discuss more theoretical topics, as well as when and how to include proofs of important theorems. It also includes guidance on how to typeset equations, logical expressions, and other mathematical notation.
• WP:Manual of Style/Dates and numbers § Non-base-10 notations gives advice on formatting e.g. binary or hexadecimal numbers and memory addresses.

Samples of actual sources get included in articles for a variety of reasons, although the most typical reasons are to demonstrate the "look" of a particular language, to provide examples of language-specific constructs or features, and to provide examples of algorithms not easily expressed in pseudocode. While there's nothing inherently wrong with including sample code, excessive amounts of it can detract from the content of the article itself; avoid writing sample code unless it contributes significantly to a fundamental understanding of the encyclopedic content.

The WikibookAlgorithm Implementation has a page on the topic of:Bogosort

Wikipedia is not a source code repository. Code that is not relevant to encyclopedic content should be moved out of Wikipedia. WikiBooks is the appropriate Wikimedia project for existing GFDL-compatible code; in particularWikibooks:Algorithm Implementation. The externalLiteratePrograms andRosetta Code wikis are appropriate places to putnew sample implementations, along with descriptions of how those implementations work.Important note: existing implementations on Wikipediacannot be transferred to the LiteratePrograms wiki because Wikipedia content is licensed under theGFDL and/orCC-BY-SA, while LiteratePrograms uses the more liberalMIT/X11 license; relicensing existing code from GFDL/CC-BY-SA to MIT/X11 would require the permission of all copyright holders

Some general guidelines on code samples:

• Sample implementations of algorithms are fine, but every algorithm article should include apseudocode description of the core algorithm when possible, so that anyone can understand how the algorithm works. See below for guidelines on pseudocode.
• The sample should use a language that clearly illustrates the algorithm to a reader who is relatively unfamiliar with the language— even if you believe that the language is well-known. To remain language-neutral, choose languages based on clarity, not popularity. Languages that emphasize readability, such asPython andRuby, are good choices. Avoid esoteric or language-specific operations.
• Source code implementations must be compatible with theGFDL andCC-BY-SA licenses (which are incompatible with theGPL).
• Multiple source code implementations are not appropriate unless they contrast specific aspects of the codeand that contrast is important to the encyclopedic content of the article. If possible, accentuate differences by providing the alternate implementation in the same language as the original.
• All code samples should be marked up using one of the following methods:
  • Surrounding ashort, inline code sample in<code>...</code> or<syntaxhighlight lang="x" inline>
  • Surrounding ablock of code in<syntaxhighlight lang="x"> or<pre>...</pre> tags
  • Indenting each line of ablock of code by one or more spaces (invoking aninvisible "pre" tag); unlike the above method, this allows you to use basic text formatting like italic, bold, etc. in the sample. This typesets them in a monospaced typeface to ensure that spacing is preserved and provides additional information toscreen readers and users with customized CSS. Doing this is particularly important for languages where whitespace has syntactic significance— ideally we'd like people to be able to copy and paste sample code into a text editor or IDE. For example,

int main(void) {    printf("hello, world\n");    return 0;}

• Syntax highlighting may be obtained by usingSyntaxHighlight MediaWiki tag instead of<pre>...</pre>, with a specificlang attribute specifying the language name (the valuewikitext is used for MediaWiki markup). SeeExtension:SyntaxHighlight for supported languages. The following is syntax-highlighted Java code, for example, using<syntaxhighlight lang="java">:

classHelloWorld{publicstaticvoidmain(String[]args){System.out.println("Hello World!");// Print "Hello World!"}}

• Since code listings are not line-wrapped, and many people read Wikipedia in space-constrained environments, ensure that code listings have a maximum line length of 60 chars. Apply manual word wrap if necessary.

There are no universally accepted standards for presenting algorithms on Wikipedia. Below, we adot the invisible "pre" method described above. A past attempt at standardized pseudocode is archived atUser:Dcoetzee/Wikicode, though "[t]he author advises that such a proposal not be advanced again, as it is unlikely to gain consent". WithinWikiProject Computer science, the consensus has generally been that where possible, algorithms should be presented in pseudocode. The use of pseudocode is completely language agnostic, and is more NPOV with respect to programming languages in general. Pseudocode also provides far more flexibility with regard to the level of implementation detail, allowing algorithms to be presented at however high a level is required to focus on the algorithm and its core ideas, rather than the details of how it is implemented. Finally, suitably high-level pseudocode provides the mostaccessible presentation of an algorithm, particularly for non-programmers.

algorithm ford-fulkersonisinput: GraphG with flow capacityc,            source nodes,            sink nodetoutput: Flowf such thatf is maximal froms tot(Note that f(u,v) is the flow from node u to node v, and c(u,v) is the flow capacity from node u to node v)for each edge (u,v)inGEdof(u,v) ← 0f(v,u) ← 0while there exists a pathp froms totin the residual networkGfdo        letcf be the flow capacity of the residual networkGfcf(p) ← min{cf(u,v) | (u,v)inp}for each edge (u,v)inpdof(u,v) ←f(u,v) +cf(p)f(v,u) ← −f(u,v)returnf

• Make sure the algorithm is understandable without having to read this page first.
• Try to focus on outlining the algorithm, and where possible keep discussion and explanation of the algorithm outside of the pseudocode.
• All assignment, comparison, and other mathematical operators should be rendered with proper mathematical symbols wherever possible:

• All control structure keywords should be bolded, and comments should be in italics (in addition to whatever other manner for denoting comments is used).
• Try to keep the algorithm description sufficiently high level so as to avoid most implementation specific details.
• Try to avoid using structures or techniques that are idiomatic to a particular language or programming paradigm.
• If idiomatic structures or techniques areunavoidable try to present them in a generic high-level way in line with the style outlined below:
• The preferred conditional structure is

if conditionthencode pathelse if conditionthencode pathelsecode pathend if

• The preferred looping constructs are

while conditiondocode blockrepeat

and

for loop_controldocode blockrepeat

whereloop_control is any suitable clause to control a for loop, such asitemin list or1 ≤ i ≤ n etc.

• The preferred function definition structure is

function function_nameiscode blockreturn variableend function

wherefunction_name is any reasonable format of function name and arguments. Alternatively, inputs and outputs can be specified within the function block:

function function_nameisinput:description of inputsoutput:description of outputscode blockreturn variableend function

• Code blocks should be indented. If sufficiently clear, block closing keywords (end,repeat etc.) may be omitted.

An example of pseudocode roughly hewing to these guidelines is provided as the example on theAlgorithm page, and inBucket sort,Topological sort, andPollard's rho algorithm.

• Algorithms that are most easily presented at a very high level, such asBuchberger's algorithm or thePohlig–Hellman algorithm should be presented in the format

Inputsdescription of input arguments

Outputdescription of outputs

1. (description of a step in the algorithm)
2. (the next step in the algorithm)
   1. (substep)
3. (etc.)

using markup:

:'''Inputs'''''description of input arguments'':'''Output'''''description of outputs'':#''(description of a step in the algorithm)'':#''(the next step in the algorithm)'':##''(substep)'':#''(etc.)''

• Descriptions of steps should be high level, and may simply be English sentences.
• Substeps of the algorithm, due to branch conditions or loop structures should be indented and subnumbered.
• Termination of the algorithm with a return value should be denoted using the keywordreturn

Examples of algorithms in this format includeBuchberger's algorithm,Pohlig–Hellman algorithm,Itoh–Tsujii inversion algorithm,Baby-step giant-step, andPollard'sp − 1 algorithm.

It isessential for article content to be verifiable with reliable sources, a well-chosen list of references and pointers to the literature. Any quotation, any material challenged or likely to be challenged, and any claim that involves a living personmust be supported by aninline citation to a reliable secondary source. Some additional reasons for citing high-quality sources are the following:

• Providing proper source citations enables other editors and our readers to verify the given information and evaluate the sources. This is especially important in any science topic, since the state of the art is always advancing.
• A reader may desire more details, but Wikipedia is not asubstitute for a textbook (that is whatWikibooks is for). Many research papers and books of benefit to topical newcomers are now freely available online.
• Some notions are defined differently depending on context or author. Articles require references that support the given usage, and should identify conflicting usages (givingdue weight to the sources for them).
• Important algorithms, theorems, or definitions should cite the concept-originating papers as historical and technical information, in addition to later secondary reference works relied on for modern, applied context.

Primary sources must be used with care. They aregenerally permissible for non-controversial and non-promotional claims about the subject or its author(s). Examples: referencing a blog post from theRust programming language development team is sufficient for a point about the internal architecture of the Rust compiler, or the motivation behind a specific decision about the Rust language design. However, such a source cannot be used for providing Rust benchmarks, or contrasting Rust's features versus those of another language, since such claims from the developers may have a promotional element and involve analysis, evaluation, interpretation, or synthesis of facts and evidence, whichrequires a secondary source.

Wikipedia does not enforce a specific reference and citation style; just use one consistently within a particular article.

• Wikipedia:WikiProject Computer science
• WP:MOSBPS - style guide for data rates

• Zobel, Justin (2004).Writing for Computer Science (2nd ed.). Springer.ISBN 1-85233-802-4.

• Wikipedia Manual of Style (science)
• WikiProject Computer science

• Pages using sidebar with the child parameter