← Back to results

.1 200 OK date: Thu, 02 Jul 2026 13:03:10 GMT server: mw-web.codfw.main-59656c8c96-kzn8s x-content-type-options: nosniff content-language: en accept-ch: reporting-endpoints: csp-report-to-endpoint='/w/api.php?action=cspreport&format=json'; content-security-policy: script-src 'unsafe-eval' blob: 'self' meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikifunctions.org *.wikivoyage.org *.mediawiki.org mediawiki.org wikimedia.org *.wmflabs.org *.wmcloud.org *.toolforge.org wss://*.toolforge.org *.jsdelivr.net unpkg.com cdnjs.cloudflare.com raw.githubusercontent.com *.github.com code.jquery.com cdn.mathjax.org use.typekit.net fonts.cdnfonts.com use.fontawesome.com i.ytimg.com rsms.me doi.org localhost https://localhost:* http://localhost:* wss://localhost:* ws://localhost:* *.google.com *.gstatic.com *.googleapis.com *.translate.yandex.net yastatic.net ya.ru radically.github.io cdn.sammdot.ca cdn.fontshare.com viaf.org publicai-proxy.alaexis.workers.dev iiif.archive.org api.flickr.com live.staticflickr.com api.anthropic.com api.openai.com api.publicai.co catalogo.pusc.it parsifal.urbe.it opac.sbn.it overpass-api.de api.openrouteservice.org archive.org *.openstreetmap.org *.waymarkedtrails.org *.thunderforest.com registry.ipe.wiki analytics.ipe.wiki qlever.dev app.goacoustic.com wikipedia-archive.ourworldindata.org api.inaturalist.org inaturalist-open-data.s3.amazonaws.com validator.w3.org db.onlinewebfonts.com fontlibrary.org 'unsafe-inline' auth.wikimedia.org; default-src 'self' data: blob: upload.wikimedia.org https://commons.wikimedia.org meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikifunctions.org *.wikivoyage.org *.mediawiki.org mediawiki.org wikimedia.org *.wmflabs.org *.wmcloud.org *.toolforge.org wss://*.toolforge.org *.jsdelivr.net unpkg.com cdnjs.cloudflare.com raw.githubusercontent.com *.github.com code.jquery.com cdn.mathjax.org use.typekit.net fonts.cdnfonts.com use.fontawesome.com i.ytimg.com rsms.me doi.org localhost https://localhost:* http://localhost:* wss://localhost:* ws://localhost:* *.google.com *.gstatic.com *.googleapis.com *.translate.yandex.net yastatic.net ya.ru radically.github.io cdn.sammdot.ca cdn.fontshare.com viaf.org publicai-proxy.alaexis.workers.dev iiif.archive.org api.flickr.com live.staticflickr.com api.anthropic.com api.openai.com api.publicai.co catalogo.pusc.it parsifal.urbe.it opac.sbn.it overpass-api.de api.openrouteservice.org archive.org *.openstreetmap.org *.waymarkedtrails.org *.thunderforest.com registry.ipe.wiki analytics.ipe.wiki qlever.dev app.goacoustic.com wikipedia-archive.ourworldindata.org api.inaturalist.org inaturalist-open-data.s3.amazonaws.com validator.w3.org db.onlinewebfonts.com fontlibrary.org en.wikibooks.org en.wikinews.org en.wikiquote.org en.wikisource.org en.wikiversity.org en.wikivoyage.org en.wiktionary.org www.mediawiki.org commons.wikimedia.org foundation.wikimedia.org incubator.wikimedia.org species.wikimedia.org wikimania.wikimedia.org www.wikidata.org www.wikifunctions.org auth.wikimedia.org; style-src 'self' data: blob: upload.wikimedia.org https://commons.wikimedia.org meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikifunctions.org *.wikivoyage.org *.mediawiki.org mediawiki.org wikimedia.org *.wmflabs.org *.wmcloud.org *.toolforge.org wss://*.toolforge.org *.jsdelivr.net unpkg.com cdnjs.cloudflare.com raw.githubusercontent.com *.github.com code.jquery.com cdn.mathjax.org use.typekit.net fonts.cdnfonts.com use.fontawesome.com i.ytimg.com rsms.me doi.org localhost https://localhost:* http://localhost:* wss://localhost:* ws://localhost:* *.google.com *.gstatic.com *.googleapis.com *.translate.yandex.net yastatic.net ya.ru radically.github.io cdn.sammdot.ca cdn.fontshare.com viaf.org publicai-proxy.alaexis.workers.dev iiif.archive.org api.flickr.com live.staticflickr.com api.anthropic.com api.openai.com api.publicai.co catalogo.pusc.it parsifal.urbe.it opac.sbn.it overpass-api.de api.openrouteservice.org archive.org *.openstreetmap.org *.waymarkedtrails.org *.thunderforest.com registry.ipe.wiki analytics.ipe.wiki qlever.dev app.goacoustic.com wikipedia-archive.ourworldindata.org api.inaturalist.org inaturalist-open-data.s3.amazonaws.com validator.w3.org db.onlinewebfonts.com fontlibrary.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json; report-to csp-report-to-endpoint last-modified: Thu, 18 Jun 2026 13:03:10 GMT content-type: text/html; charset=UTF-8 age: 2 accept-ranges: bytes x-cache: cp2047 miss, cp2047 miss x-cache-status: miss server-timing: cache;desc="miss", host;desc="cp2047" strict-transport-security: max-age=106384710; includeSubDomains; preload report-to: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] } nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0} set-cookie: WMF-Last-Access=02-Jul-2026;Path=/;HttpOnly;secure;Expires=Mon, 03 Aug 2026 12:00:00 GMT set-cookie: WMF-Last-Access-Global=02-Jul-2026;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Mon, 03 Aug 2026 12:00:00 GMT set-cookie: WMF-DP=09d;Path=/;HttpOnly;secure;Expires=Fri, 03 Jul 2026 00:00:00 GMT x-client-ip: 75.28.18.94 cache-control: private, s-maxage=0, max-age=0, must-revalidate, no-transform vary: Accept-Encoding,X-Subdomain,Cookie,Authorization,User-Agent set-cookie: GeoIP=US:TX:McKinney:33.20:-96.62:v4; Path=/; secure; Domain=.wikipedia.org set-cookie: NetworkProbeLimit=0.001;Path=/;Secure;SameSite=None;Max-Age=3600 set-cookie: WMF-Uniq=ilIt81c1G01XrtMNYKycqAORAAAAAFvdLUPcGpKAYtKcsKTPuYFpxbRYK48uKn3B;Domain=.wikipedia.org;Path=/;HttpOnly;secure;SameSite=None;Expires=Fri, 02 Jul 2027 00:00:00 GMT transfer-encoding: chunked x-request-id: 18ee7607-2550-4531-a6c1-7f2b20f9d970 x-analytics: 8000 Code coverage - Wikipedia Jump to content Main menu Main menu move to sidebar hide Navigation Main page Contents Current events Random article About Wikipedia Contact us Contribute Help Learn to edit Community portal Recent changes Upload file Special pages Search Search Appearance Donate Create account Log in Personal tools Donate Create account Log in Contents move to sidebar hide (Top) 1 Coverage criteria Toggle Coverage criteria subsection 1.1 Basic coverage criteria 1.2 Modified condition/decision coverage 1.3 Multiple condition coverage 1.4 Parameter value coverage 1.5 Other coverage criteria 2 In practice Toggle In practice subsection 2.1 Notable code coverage tools 2.1.1 Hardware manufacturers 2.1.2 Software 2.1.2.1 C / C++ 2.1.2.2 C# .NET 2.1.2.3 Java 2.1.2.4 PHP 3 Usage in industry 4 See also 5 References Toggle the table of contents Code coverage 16 languages Alemannisch العربية Беларуская Català Čeština Deutsch Español Français עברית 日本語 한국어 Polski Português Русский Українська 中文 Edit links Article Talk English Read Edit View history Tools Tools move to sidebar hide Actions Read Edit View history General What links here Related changes Upload file Permanent link Page information Cite this page Get shortened URL Switch to legacy parser Print/export Download as PDF Printable version In other projects Wikidata item Appearance move to sidebar hide From Wikipedia, the free encyclopedia Metric for source code testing This article is about coverage based on source code. For coverage based on requirements, see Test coverage . Program execution General concepts Code Translation Compiler Compile time Optimizing compiler Linking Execution Runtime system Executable Interpreter Virtual machine Intermediate representation (IR) Types of code Source code Object code Bytecode Machine code Microcode Compilation strategies Ahead-of-time (AOT) Just-in-time (JIT) Tracing just-in-time Compile and go system Precompilation Transcompilation Recompilation Meta-tracing Notable runtimes Android Runtime (ART) BEAM (Erlang) Common Language Runtime (CLR) and   Mono CPython and   PyPy crt0 ( C target-specific initializer) Java virtual machine (JVM) LuaJIT Objective-C and   Swift 's V8 and   Node.js Zend Engine (PHP) Notable compilers & toolchains GNU Compiler Collection (GCC) LLVM and   Clang MSVC Glasgow Haskell Compiler (GHC) v t e In software engineering , code coverage , also called test coverage , is a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run. A program with high code coverage has more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low code coverage. [ 1 ] [ 2 ] Many different metrics can be used to calculate test coverage. Some of the most basic are the percentage of program subroutines and the percentage of program statements called during execution of the test suite. Code coverage was among the first methods invented for systematic software testing . The first published reference was by Miller and Maloney in Communications of the ACM , in 1963. [ 3 ] Coverage criteria [ edit ] To measure what percentage of code has been executed by a test suite , one or more coverage criteria are used. These are usually defined as rules or requirements, which a test suite must satisfy. [ 4 ] Basic coverage criteria [ edit ] There are a number of coverage criteria, but the main ones are: [ 5 ] Function coverage   – has each function (or subroutine ) in the program been called? Statement coverage   – has each statement in the program been executed? Edge coverage   – has every edge in the control-flow graph been executed? Branch coverage   – has each branch (also called the DD-path ) of each control structure (such as in if and case statements ) been executed? For example, given an if statement, have both the true and false branches been executed? (This is a subset of edge coverage . ) Condition coverage   – has each Boolean sub-expression evaluated both to true and false? (Also called predicate coverage.) For example, consider the following C function: 0) && (y > 0))\n {\n z = x;\n }\n return z;\n}\n"}}'> int foo ( int x , int y ) { int z = 0 ; if (( x > 0 ) && ( y > 0 )) { z = x ; } return z ; } Assume this function is a part of some bigger program and this program was run with some test suite. Function coverage will be satisfied if, during this execution, the function foo was called at least once. Statement coverage for this function will be satisfied if it was called for example as foo(1,1) , because in this case, every line in the function would be executed—including z = x; . Branch coverage will be satisfied by tests calling foo(1,1) and foo(0,1) because, in the first case, both if conditions are met and z = x; is executed, while in the second case, the first condition, (x>0) , is not satisfied, which prevents the execution of z = x; . Condition coverage will be satisfied with tests that call foo(1,0) , foo(0,1) , and foo(1,1) . These are necessary because in the first case, (x>0) is evaluated to true , while in the second, it is evaluated to false . At the same time, the first case makes (y>0) false , the second case does not evaluate (y>0) (because of the lazy-evaluation of the Boolean operator), the third case makes it true . In programming languages that do not perform short-circuit evaluation , condition coverage does not necessarily imply branch coverage. For example, consider the following Pascal code fragment: if a and b then Condition coverage can be satisfied by two tests: a=true , b=false a=false , b=true However, this set of tests does not satisfy branch coverage since neither case will meet the if condition. Fault injection may be necessary to ensure that all conditions and branches of exception-handling code have adequate coverage during testing. Modified condition/decision coverage [ edit ] Main article: Modified condition/decision coverage A combination of function coverage and branch coverage is sometimes also called decision coverage . This criterion requires that every point of entry and exit in the program has been invoked at least once, and every decision in the program has taken on all possible outcomes at least once. In this context, the decision is a Boolean expression comprising conditions and zero or more Boolean operators. This definition is not the same as branch coverage, [ 6 ] however, the term decision coverage is sometimes used as a synonym for it. [ 7 ] Condition/decision coverage requires that both decision and condition coverage be satisfied. However, for safety-critical applications (such as avionics software ) it is often required that modified condition/decision coverage (MC/DC) be satisfied. This criterion extends condition/decision criteria with requirements that each condition should affect the decision outcome independently. For example, consider the following code: if ( a or b ) and c then The condition/decision criteria will be satisfied by the following set of tests: a b c true true true false false false However, the above tests set will not satisfy modified condition/decision coverage, since in the first test, the value of 'b' and in the second test the value of 'c' would not influence the output. So, the following test set is needed to satisfy MC/DC: a b c false true false false true true false false true true false true Multiple condition coverage [ edit ] This criterion requires that all combinations of conditions inside each decision are tested. For example, the code fragment from the previous section will require eight tests: a b c false false false false false true false true false false true true true false false true false true true true false true true true Parameter value coverage [ edit ] Parameter value coverage (PVC) requires that in a method taking parameters, all the common values for such parameters be considered. The idea is that all common possible values for a parameter are tested. [ 8 ] For example, common values for a string are: 1) null , 2) empty, 3) whitespace (space, tabs, newline), 4) valid string, 5) invalid string, 6) single-byte string, 7) double-byte string. It may also be appropriate to use very long strings. Failure to test each possible parameter value may result in a bug. Testing only one of these could result in 100% code coverage as each line is covered, but as only one of seven options are tested, there is only 14.2% PVC. Other coverage criteria [ edit ] There are further coverage criteria, which are used less often: Linear Code Sequence and Jump (LCSAJ) coverage a.k.a. JJ-Path coverage   – has every LCSAJ/JJ-path been executed? [ 9 ] Path coverage   – Has every possible route through a given part of the code been executed? Entry/exit coverage   – Has every possible call and return of the function been executed? Loop coverage   – Has every possible loop been executed zero times, once, and more than once? State coverage   – Has each state in a finite-state machine been reached and explored? Data-flow coverage   – Has each variable definition and its usage been reached and explored? [ 10 ] Safety-critical or dependable applications are often required to demonstrate 100% of some form of test coverage. For example, the ECSS -E-ST-40C standard demands 100% statement and decision coverage for two out of four different criticality levels; for the other ones, target coverage values are up to negotiation between supplier and customer. [ 11 ] However, setting specific target values - and, in particular, 100% - has been criticized by practitioners for various reasons (cf. [ 12 ] ) Martin Fowler writes: "I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing". [ 13 ] Some of the coverage criteria above are connected. For instance, path coverage implies decision, statement and entry/exit coverage. Decision coverage implies statement coverage, because every statement is part of a branch. Full path coverage, of the type described above, is usually impractical or impossible. Any module with a succession of n {\displaystyle n} decisions in it can have up to 2 n {\displaystyle 2^{n}} paths within it; loop constructs can result in an infinite number of paths. Many paths may also be infeasible, in that there is no input to the program under test that can cause that particular path to be executed. However, a general-purpose algorithm for identifying infeasible paths has been proven to be impossible (such an algorithm could be used to solve the halting problem ). [ 14 ] Basis path testing is for instance a method of achieving complete branch coverage without achieving complete path coverage. [ 15 ] Methods for practical path coverage testing instead attempt to identify classes of code paths that differ only in the number of loop executions, and to achieve "basis path" coverage the tester must cover all the path classes. [ 16 ] [ clarification needed ] In practice [ edit ] The target software is built with special options or libraries and run under a controlled environment, to map every executed function to the function points in the source code. [ 17 ] This allows testing parts of the target software that are rarely or never accessed under normal conditions, and helps reassure that the most important conditions (function points) have been tested. The resulting output is then analyzed to see what areas of code have not been exercised and the tests are updated to include these areas as necessary. Combined with other test coverage methods, the aim is to develop a rigorous, yet manageable, set of regression tests. In implementing test coverage policies within a software development environment, one must consider the following: What are coverage requirements for the end product certification and if so what level of test coverage is required? The typical level of rigor progression is as follows: Statement, Branch/Decision, Modified Condition/Decision Coverage (MC/DC), LCSAJ ( Linear Code Sequence and Jump ) Will coverage be measured against tests that verify requirements levied on the system under test ( DO-178B )? Is the object code generated directly traceable to source code statements? Certain certifications, (i.e. DO-178B Level A) require coverage at the assembly level if this is not the case: "Then, additional verification should be performed on the object code to establish the correctness of such generated code sequences" ( DO-178B ) para-6.4.4.2. [ 18 ] Software authors can look at test coverage results to devise additional tests and input or configuration sets to increase the coverage over vital functions. Two common forms of test coverage are statement (or line) coverage and branch (or edge) coverage. Line coverage reports on the execution footprint of testing in terms of which lines of code were executed to complete the test. Edge coverage reports which branches or code decision points were executed to complete the test. They both report a coverage metric, measured as a percentage. The meaning of this depends on what form(s) of coverage have been used, as 67% branch coverage is more comprehensive than 67% statement coverage. Generally, test coverage tools incur computation and logging in addition to the actual program thereby slowing down the application, so typically this analysis is not done in production. As one might expect, there are classes of software that cannot be feasibly subjected to these coverage tests, though a degree of coverage mapping can be approximated through analysis rather than direct testing. There are also some sorts of defects which are affected by such tools. In particular, some race conditions or similar real time sensitive operations can be masked when run under test environments; though conversely, some of these defects may become easier to find as a result of the additional overhead of the testing code. Most professional software developers use C1 and C2 coverage. C1 stands for statement coverage and C2 for branch or condition coverage. With a combination of C1 and C2, it is possible to cover most statements in a code base. Statement coverage would also cover function coverage with entry and exit, loop, path, state flow, control flow and data flow coverage. With these methods, it is possible to achieve nearly 100% code coverage in most software projects. [ 19 ] Notable code coverage tools [ edit ] Hardware manufacturers [ edit ] Aldec Mentor Graphics Silvaco Synopsys Software [ edit ] LDRA Testbed Parasoft C / C++ [ edit ] Cantata++ Gcov Insure++ LDRA Testbed Tcov Testwell CTC++ Trucov Squish (Froglogic) C# .NET [ edit ] DevPartner Studio JetBrains NCover Java [ edit ] Main article: Java code coverage tools Clover DevPartner Java EMMA Jtest LDRA Testbed PHP [ edit ] PHPUnit , also need Xdebug to make coverage reports Usage in industry [ edit ] Test coverage is one consideration in the safety certification of avionics equipment. The guidelines by which avionics gear is certified by the Federal Aviation Administration (FAA) is documented in DO-178B [ 18 ] and DO-178C . [ 20 ] Test coverage is also a requirement in part 6 of the automotive safety standard ISO 26262 Road Vehicles - Functional Safety . [ 21 ] See also [ edit ] Cyclomatic complexity Intelligent verification Linear code sequence and jump Modified condition/decision coverage Mutation testing Regression testing Software metric Static program analysis White-box testing Java code coverage tools References [ edit ] ↑ Brader, Larry; Hilliker, Howie; Wills, Alan (March 2, 2013). "Chapter 2 Unit Testing: Testing the Inside". Testing for Continuous Delivery with Visual Studio 2012 . Microsoft. p.   30. ISBN   978-1621140184 . Retrieved 16 June 2016 . ↑ Williams, Laurie ; Smith, Ben; Heckman, Sarah. "Test Coverage with EclEmma" . Open Seminar Software Engineering . North Carolina State University. Archived from the original on 14 March 2016 . Retrieved 16 June 2016 . ↑ Joan C. Miller, Clifford J. Maloney (February 1963). "Systematic mistake analysis of digital computer programs" . Communications of the ACM . 6 (2). New York, NY, USA: ACM : 58– 63. doi : 10.1145/366246.366248 . ISSN   0001-0782 . ↑ Paul Ammann, Jeff Offutt (2013). Introduction to Software Testing . Cambridge University Press. ↑ Glenford J. Myers (2004). The Art of Software Testing, 2nd edition . Wiley. ISBN   0-471-46912-2 . ↑ Position Paper CAST-10 (June 2002). What is a "Decision" in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)? ↑ MathWorks. Types of Model Coverage. ↑ "Unit Testing with Parameter Value Coverage (PVC)" . 8 May 2012. ↑ M. R. Woodward, M. A. Hennell, "On the relationship between two control-flow coverage criteria: all JJ-paths and MCDC", Information and Software Technology 48 (2006) pp. 433-440 ↑ Ting Su, Ke Wu, Weikai Miao, Geguang Pu, Jifeng He, Yuting Chen, and Zhendong Su. "A Survey on Data-Flow Testing". ACM Comput. Surv. 50, 1, Article 5 (March 2017), 35 pages. ↑ ECSS-E-ST-40C: Space engineering - Software. ECSS Secretariat, ESA-ESTEC. March, 2009 ↑ C. Prause, J. Werner, K. Hornig, S. Bosecker, M. Kuhrmann (2017): Is 100% Test Coverage a Reasonable Requirement? Lessons Learned from a Space Software Project . In: PROFES 2017. Springer. Last accessed: 2017-11-17 ↑ Martin Fowler's blog: TestCoverage. Last accessed: 2017-11-17 ↑ Dorf, Richard C.: Computers, Software Engineering, and Digital Devices , Chapter 12, pg. 15. CRC Press, 2006. ISBN   0-8493-7340-9 , ISBN   978-0-8493-7340-4 ; via Google Book Search ↑ Y.N. Srikant; Priti Shankar (2002). The Compiler Design Handbook: Optimizations and Machine Code Generation . CRC Press. p.   249. ISBN   978-1-4200-4057-9 . ↑ Marcozzi, M.; Bardin, Sébastien; Kosmatov, N.; Papadakis, Mike; Prevosto, Virgile; Correnson, Loïc (2018). "Time to clean your test objectives". Proceedings of the 40th International Conference on Software Engineering . pp.   456– 467. doi : 10.1145/3180155.3180191 . ISBN   978-1-4503-5638-1 . ↑ Garousi, Vahid; Keleş, Alper Buğra; Balaman, Yunus; Mermer, Alper; Güler, Zeynep Özdemir (May 2024). "Coverage measurement in model-based testing of web applications: Tool support and an industrial experience report". 2024 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW) . pp.   37– 43. doi : 10.1109/icstw60967.2024.00019 . ISBN   979-8-3503-4479-0 . 1 2 RTCA/ DO-178B , Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, December 1, 1992 ↑ Boris beizer (2009). Software testing techniques, 2nd edition . Dreamtech press. ISBN   978-81-7722-260-9 . ↑ RTCA/ DO-178C , Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, January, 2012. ↑ ISO 26262-6:2011(en) Road vehicles -- Functional safety -- Part 6: Product development at the software level . International Standardization Organization. Retrieved from " https://en.wikipedia.org/w/index.php?title=Code_coverage&oldid=1355385285 " Categories : Software metrics Software testing tools Hidden categories: Articles with short description Short description is different from Wikidata Wikipedia articles needing clarification from July 2014 This page was last edited on 21 May 2026, at 15:00  (UTC) . Page was rendered with Parsoid . Text is available under the Creative Commons Attribution-ShareAlike 4.0 License ; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy . Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. , a non-profit organization. Privacy policy About Wikipedia Disclaimers Contact Wikipedia Legal & safety contacts Code of Conduct Developers Statistics 275B Cookie statement Mobile view Search Search Toggle the table of contents Code coverage 16 languages Add topic 0