When writing articles on computers, computer software, computer networking, the Internet and information technology, please consider the following style guidelines. Other policies and guidelines should also be followed.

Avoid abbreviations and acronyms, except when the subject is almost never spelled out. For example, Voice over Internet Protocol is the acceptable title, but not Voice over IP or VoIP. In the body however, acronyms may be used, provided that they are spelled out all on their first use; put the acronym in parentheses after the spelled-out name.

Never use parentheses at the end of article titles to show acronyms, e.g., do not use Voice over IP (VoIP). This notation is used to disambiguate a computer term from another article using the same name. For example, this notation is used to disambiguate cookie (computing) from cookie.

Do not overuse capital letters. Do not use capital letters for each word of a phrase just because the phrase is the article title, is a heading or has a corresponding acronym in parentheses. Standards documents or marketing material often overuse capital letters. Wikipedia style, however, uses more common English style of using capital letters only for true proper names. Some terms start as proper names and then become applied to generic concepts. Normal English is used for normal English words, while initial capitals can be used when the word is a newly coined one, such as Ethernet.

Use the most common name for the title. When a technology is defined by an official standard or standards body, use its common name as article title (such as 10 Gigabit Ethernet) but create a redirect for the official or technical names (such as IEEE 802.3ae). In some cases such as Wi-Fi, the common (in this case, trademarked) name can have a separate article from the standard, when they are independently notable enough to justify separate articles. Each edition or amendment to the standard need not have its own article, unless they are separately notable such as IEEE 802.11n-2009 and IEEE 802.11g-2003.

For computer technology trademarks, please adhere to Wikipedia policies and style guidelines regarding trademarks. For trademarks in all capital letters or all small letters, use standard English: Use initial capital letter. For example, Unix instead of UNIX. There is no reason to explain this in the body of each article.

Keep in mind what Wikipedia is not. Since it is not a dictionary, each term or product does not always get its own article; combine them into topics that can have a high quality encyclopedia article written on them.

Avoid just pasting lists of features into the article, since they can become dated or removed as advertisement or copyright violations. Avoid relative time references (such as "currently", "lately" or "now").

Each software product version must be referred to with the most common name.

Software vendors often use one of the following approaches to refer to a specific version of a software product:

1. They include the version number in their reference, e.g. WinRAR 4, WinRAR version 3 and WinRAR v2.
2. They change the product name with each release, e.g. Windows Vista and Windows 7.

Video games add a twist to this scheme. Video game vendors often make sequels and prequels for their most notable products. They use numbers in their video game titles to show their relationship. For instance Red Alert 2 and Red Alert 3 are two distinct but related video games. However, numbers that are part of the title are not version numbers. A separate version number may still be used. For instance, Red Alert 2 v1.008 is an updated version of Red Alert 2.

Consistently use the most common product name. For example, use (Windows XP, not Windows v5.1 or Windows NT v5.1). Do not confuse and combine these methods, e.g. never use Red Alert v2 or Red Alert version 2 to refer to Red Alert 2. Do not invent novel short forms and abbreviations.

Service packs or service releases are computer software that modify other computer software to fix their bugs or improve them. When referring to service packs, please make proper distinction between the version of software product which is serviced via a service pack and the service pack itself.

To refer to a service pack, write down the full name of service pack. For example:

• Windows XP Service Pack 2
• WinZip 9 Service Release 1

To refer to a software product updated with a service pack, write: [Product name] with [Service pack name].

• Windows XP with Service Pack 2
• WinZip 9 with Service Release 1

Alternatively, you can specify the version identifier of the software product for conciseness. For example:

• Windows XP SP2
• WinZip 9 SR-1

Try to use one of these two styles consistently throughout the entire article prose: Using both may confuse the readers with little technical knowledge as they may not understand that both forms refer to the same entity.

Do not use these two terms (that are sometimes used interchangeably) in a manner that causes ambiguity or limits the audience of the article.

x86 is a type of CPU first developed by Intel corporation, and later by others. There are two different variations of x86 in widespread use: IA-32 and x64. However, due to the dominance of IA-32, the term "x86" is often used to refer to IA-32. (See metonymy.) Therefore, these terms must be used with care.

Example of correct usage:

• "This computer program runs on x86."
• "This computer program runs on IA-32 or x64."
• "This computer program runs on IA-32 but not x64."

Examples of incorrect usage:

• "This computer program runs on x86 but not x64."
• "This computer program runs on x86 or x64."

Do not use the terms 32-bit and 64-bit (or other bit lengths) to refer to computer architectures or models. These terms are too vague and can cause a lot of ambiguity or misinformation.

These terms are often used to refer to two well-known CPU architecture types: IA-32 (a 32-bit variant of x86) and x64 (a 64-bit variant of x86). However, neither is IA-32 the only 32-bit CPU architecture in the world nor is x64 the only 64-bit CPU architecture available.

Examples of incorrect usage:

• "This software application only runs on 64-bit CPUs."
• "This software application runs on 8-bit CPUs."

Example of correct usage:

• "This software application only runs on x64 CPUs."
• "This software application runs on MOS 6502 CPUs."
• "This software application runs on Zilog Z80 CPUs."

In Wikipedia, everything needs sources, including but not limited to software release dates, software package sizes, supported languages and the programming languages used to develop software products. Avoid tagging a computer program as "Multilingual" or "written in C++" without a source.

Avoid using strange forms of language. On the contrary, editors must stick to the most commonly used forms to make sure the readers feel at home. Do not use synonyms of a certain words just because they are synonyms; collocation is very important.

For instance:

1. Computer programs that are no longer developed are called "abandonware". Do not use "forgottenware". (See abandonware)
2. The act of ceasing development of a software product is called "discontinuation". Do not use "abandonment". (See software release cycle and end-of-life (product))
3. Computer programs run on a certain operating system or platform. Do not use "run under" or "run beneath".
4. Computer programs run in context or within the context of a user account. Do not use "under", "beneath", "on", "inside" or "over". While these variations may be okay in informal speech, Wikipedia:Featured article criteria demands the use of professional style.
5. "Log on", "Log in" and "Sign in" are all verbs that mean to "supply credentials for authentication". However, users either "log on to their computers" or "log in to their computers". They never "sign in to their computers". "Sign in" is only used for the authentication over the Internet. (See login)
6. "Disc" and "disk" both refer to digital storage media. However, "disc" collocates with optical media, as in Compact Disc, Template:Blu-ray Disc, while "disk" collocates with magnetic media, as in hard disk, floppy disk and solid state disk.

The Arbitration Committee has ruled that editors should not change an article from one guideline-defined style to another without a substantial reason unrelated to mere choice of style. Revert-warring over optional styles is unacceptable.^[1] Where there is disagreement over which of the styles to use in an article, maintain status quo.

Do not edit-war over:

• Choosing one of the many synonyms for a concept, e.g. "shareware", "trialware" or other synonyms; "x64" or "x86-64"; "Proprietary software" or "closed-source"
• Using one word or many word for the same concept, e.g. "x86" or "IA-32 and x64"
• Ascending or descending sort order
• Inserting one of the multiple URLs that all point to the same place and none has any advantage over the other
• Any other multiple forms of the same thing

Command-line examples are used to illustrate the syntax of shell commands or programs as a user would type them into a terminal or command-line interpreter on a computer. This page is a style guide for articles related to computer science on Wikipedia.

When providing command-line examples, maintain clarity and simplicity. It prevents the reader from becoming confused. The following guidelines help define clear and simple examples.

• Command-line examples should be presented in a monospaced font. The initial presentation should use the Wikipedia method that involves prefixing commands with a space. Further references should be contained in <code> tags.
• Avoid referencing environment variables, dates, working directories, usernames, and hostnames unless they are relevant in the example.
• Terminology: An option is a switch (something that modifies the general behavior of the command). A parameter is a specific value, such as a file or hostname. The term argument is used to refer to any of the strings that follow a command name, including both options and parameters. See Parameter (computing)#Parameters and arguments.
• When presenting arguments, maintain simplicity. Specifying them without explanation can confuse the reader.
• Do not document the entire list of options associated with a command unless there are very few such options or such descriptiveness is necessary. Wikipedia is not a substitute for manual pages.
• Use logical names in italics for parameters. These names should not contain spaces, as spaces are used to separate multiple arguments on the command line. The following are some examples:
  • (prompt) command parameter-name
  • (prompt) command parameterName
  • (prompt) command parameter_name
  • (prompt) command parametername

Consistency is important. For example, do not confuse the reader by using all four methods of naming parameters in the same article.

• Enclose optional arguments with square brackets: [ and ].
• The following are the two most common ways of specifying repeating parameters:
  • (prompt) command parameter0 [.. parameterN]
  • (prompt) command [parameter ...]

The most common operating system in use today is Microsoft Windows, whose command-line syntax is based on that of MS-DOS. As such, examples that might be specific to MS-DOS or Windows do not need to indicate this. However, if the examples are specific to a certain version of the operating system, then this should be indicated. If equivalents in other versions of DOS differ and are known, provide them.

The following additional guidelines are for DOS command-line examples:

• Write the names of commands and programs all upper-case letters.
• Standard MS-DOS–style options (of the form /C where C is some character) should also be upper-case, unless they are case sensitive.
• Contrast program names against built-in command names by appending their file extension. If a program is not included with certain versions of MS-DOS (such as MOVE.EXE or EDIT.COM), then the versions for which it is known to be included should be indicated.

• Commands that are shell builtins (such as cd and history) should be indicated as such.
• Avoid shell-specific commands or utilities (such as the for loop or certain stream behaviors) whenever possible, because of the great variation in shells across Unix-like systems.
• If a shell-specific sequence is required for proper explanation, provide an example for the ALGOL-like shells (Bourne shell, Korn shell, and Bash) as well as one for the C-like syntax of C shell and tcsh.
• The names of most commands on Unix-like systems are entirely in lower-case characters. Ensure that the capitalisation given matches that of the command or file name, because the shell and operating environment is case-sensitive. Use the wrongtitle template when necessary.
• Differentiate commands that normally require privileged access from those that do not require it.
• In some cases, the value of a parameter will commonly contain shell metacharacters. In these cases, it may be wise to specify quoting in the example to prevent users from receiving errors that to them will seem strange and unrelated.

It may often be useful to provide a sample of the output that a command generates. In these cases, the full command and all arguments as they were typed are given. The output of the command will therefore be specific to environment and other variables. The tags <pre><nowiki> (in that order) will usually avoid conflicts with the wiki markup syntax.

The DIR built-in command on DOS, which lists files and directories:

> DIR [options] [pattern ...]

The program MOVE.EXE on MS-DOS (whose behavior had to be emulated prior to its introduction):

> MOVE.EXE source target

The ls command on Unix-like systems, which lists files and directories:

$ ls [options] [file ...]

The mkfs command, which creates new file systems and as such usually requires privileged access:

# mkfs [-t fstype] [fs-options] device

The Wget program, one of the GNU utilities, which retrieves files given a Uniform Resource Identifier (URI). URIs can sometimes contain shell meta-characters, and so the parameter is usually quoted to prevent errors.

$ wget [options] "URI"

The if built-in structure, whose syntax varies. In Bourne shell, Korn shell and Bash:

$ if command ; then command ; ... ; fi

In C shell and tcsh:

% if (expression) then command ; ... ; endif

Sample output of the df command, which lists disk space usage on mounted file systems:

$ df -P
Filesystem          512-blocks      Used Available Capacity Mounted on
/dev/hda2             39331760   7398904  29834768      20% /

Try to specify the licensing terms of the subject of a computer program article accurately and concisely.

License agreements usually specify one or more of the following:

1. Environment of use (e.g. commercial, non-commercial, personal, educational, non-military, etc.)
2. Cost of use (e.g. free of charge, one-time payment, subscription-based, etc.)
3. Applicable licensees (e.g. unrestricted, one computer, one user account of a computer, one user, volume licensing, etc.)
4. Other rights (e.g. the right to study, modify, reverse-engineer, etc.) or restrictions (e.g. of use for producing pornographic contents)

Wikipedia has articles about the most common software licensing schemes. Therefore, most of the times, one or two wikilinked words in the infobox can describe the licensing scheme. For instance GPL, Freemium, BSD license or Proprietary commercial software (Write: [[Proprietary software|Proprietary]] [[commercial software]]). Avoid vague or outright non-informative phrases like "Vendor’s EULA", "Multiple" and "Unknown".

Certain areas of Wikipedia such as infoboxes require website addresses (URL) written in a manner that is readable in print. However, in order to improve human-friendliness of the article, certain parts of the web addresses such as the scheme and the "www" may need to be hidden.

A web address consists of several parts. The following shows some of the most commonly-seen ones:

However, the reader of the article does not need to see all these somewhat unappealing and hard-to-remember items. Some of these items can be masked, so that while they are passed properly to the web browser, they are not seen by the reader:

1. If the scheme is http://, mask the scheme. (You may use the {{URL}} template to hide this part automatically.)
2. If the FQDN is preceded by www., mask that prefix. (You may use {{URL}} template to hide this part automatically.) Users may omit this prefix when typing the website FQDN and expect it to work properly.
   • In the rare cases that www. is required, do not omit it. Optionally, it is recommended to leave an invisible wiki-markup comment (See WP:COMMENT) for editors to know that.
3. If the request part is only a single slash character ( / ), omit it.
   • In the rare cases that this character is required, add a comment for the reader of the article.

In addition:

• If the target website provider has provided shorter alternative URLs to the webpage, use them. The only exception to this instance is short URLs that use hard-to-remember numbers. For instance:

• Do not use URL shortening services such as bit.ly. Such URLs are maintained by independent entities and are susceptible to link rot. (See also: URL shortening § Shortcomings)

• WikiProject Computer science/Manual of style (draft)
• Wikipedia:Manual of Style/Dates and numbers § Non-base-10 notations