Snake case (sometimes stylized autologically as snake_case) is the naming convention in which each space is replaced with an underscore (_) character, and words are written in lowercase. It is a commonly used naming convention in computing, for example for variable and subroutine names, and for filenames. One study has found that readers can recognize snake case values more quickly than camel case. However, "subjects were trained mainly in the underscore style", so the possibility of bias cannot be eliminated.[1]
A variation is screaming snake case, where words are written in all caps (stylized as SCREAMING_SNAKE_CASE).[2] This convention is used for constants in programming languages like C/C++, Python, Java, PHP, as well as for environment variables.
History
The use of underscores as word separators dates back to the late 1960s. It is particularly associated with C, is found in The C Programming Language (1978), and contrasted with pascal case (a type of camel case). However, the convention traditionally had no specific name: the Python programming language style guide refers to it simply as "lower_case_with_underscores".[3]
Within Usenet the term snake_case was first seen in the Ruby community in 2004,[4] used by Gavin Kistner, writing:
BTW...what *do* you call that naming style? snake_case? That's what I'll call it until someone corrects me.
Oracle SQL and PL/SQL,[19] for all unquoted identifiers (tables, columns, indexes, constraints, PL/SQL variables, constants, procedures/functions, triggers,...), although not official by Oracle itself, still recommended by the majority of known "influencers" and used throughout the official Oracle documentation
All unquoted snake_case identifiers are actually internally represented as SCREAMING_SNAKE_CASE identifiers.
Prolog, for both atoms (predicate names, function names, and constants) and variables[20]
Python, for variable names, function names, method names, and module or package (i.e. file) names[3]
^Michael A. Covington; Roberto Bagnara; Richard A. O'Keefe; Jan Wielemaker; Simon Price (2009). "Coding Guidelines for Prolog (v.3)". p. 14. arXiv:0911.2899 [cs.PL].