Why PHP Uses snake_case Functions but camelCase Methods

Built-in functions are usually snake_case. Modern framework code is usually camelCase. That is PHP: a language where naming conventions can feel oddly split. So which naming convention is actually "correct" in PHP? I'm tanahiro2010, and this is one of those small-but-persistent questions that keeps coming back whenever I write PHP. Let me say this up front: this article is not about declaring either camelCase or snake_case the one true style. Instead, it looks at why PHP's naming conventions appear to differ by layer, traces that split through PHP's history, and offers a practical way to decide how to name things in your own code. While writing this, I tried not to rely only on memory or second-hand explanations. Where possible, I checked primary sources such as the official PHP manual, the PHP-FIG website, and the PEAR manual. For historical details I could not fully verify, especially around early PHP-FIG membership and some framework-specific context, I explicitly mark them as unconfirmed or inferential. A note on terminology This article includes a few terms that may be unfamiliar if you are new to PHP or web development. When that happens, I add a short explanation in a blockquote like this. You can skip these blocks if you already know the terms; the main argument should still be readable without them. Have you seen code like this? When writing PHP, you often run into functions like these: str_replace($search, $replace, $subject); array_map($callback, $items); json_encode($payload); file_get_contents($path); As you can see, these names use snake_case : words connected with underscores. But modern PHP code, especially framework-based code, often looks more like this: $request->getParsedBody(); $response->getStatusCode(); $userRepository->findById($id); This time, the names use camelCase : words joined together, with later words starting with uppercase letters. Inside the same language, PHP, two very different-looking styles coexist. This article traces where that split came from. Table of Contents - The conclusion first - Why PHP built-in functions look like snake_case - PHP 3 and the spread of function-based web programming - PEAR: shared conventions before PSR - PHP 5 and the rise of OOP PHP - Framework culture in the late 2000s - A side note on Symfony helpers - PHP-FIG and PSR - What PSR-1 says, and what it does not say - Why naming still hurts - Practical guidelines for modern PHP - Summary 1. The conclusion first Before getting into the history, here is the conclusion of this article: - Regular functions, including global functions, helper functions, and procedural APIs: snake_case - Class methods: camelCase After looking through PHP's history, this feels like the most natural compromise to me. That said, this is not an absolute law. Always prioritize the following when they apply: - If an existing project already has a convention, follow it. - If your framework has a convention, such as Laravel, Symfony, or WordPress, follow it. - If you are naming a public API, preserving backward compatibility matters more than stylistic purity. What is PSR? PSR stands for PHP Standard Recommendation. PSRs are standards created by PHP-FIG, a group that defines coding styles and shared interfaces for the PHP ecosystem. PSR-1 and PSR-12 are examples. PSRs are not part of the PHP language specification itself; they are community standards. One important premise: PHP does not enforce naming style at the syntax level. Whether you write names in snake_case , camelCase , or something else, the PHP interpreter will usually run the code just fine. In other words, PHP lets you write code that works even if it ignores naming conventions. This becomes important later when we talk about why naming still causes pain. So why does "functions use snake_case, methods use camelCase" feel natural in PHP? Let's go back to 1995. 2. Why PHP built-in functions look like snake_case PHP did not begin as a carefully designed language PHP began as a small set of CGI binaries written by Rasmus Lerdorf in 1994 to track visits to his online resume. It was called "Personal Home Page Tools" or "PHP Tools". The source code was released in June 1995 (PHP: History of PHP - Manual). What is CGI? CGI stands for Common Gateway Interface. It is a mechanism that lets a web server call an external program and return the program's output to the browser. In the 1990s, CGI programs written in languages like Perl were a common way to generate dynamic web pages. PHP started in this world as a set of C-based executables. In September 1995, PHP evolved into "FI" or "Forms Interpreter". In April 1996, the two were combined as "PHP/FI". Then in 1997, Andi Gutmans and Zeev Suraski, who were in Tel Aviv at the time, rewrote the parser and worked with Rasmus Lerdorf to create a new language. In June 1998, PHP 3 was released as the official successor to PHP/FI 2.0. The name also changed to the recursive acronym "PHP: Hypertext Preprocessor" (PHP: History of PHP - Manual). In other words, PHP was not born from the sequence "design a complete language specification, then implement it." It grew from practical personal tools into a language because people needed it. Nobody was designing API naming conventions in anticipation of a massive global ecosystem thirty years later. That is the first point to keep in mind. A function culture grew from there Useful web development features, such as string handling, array operations, file operations, and database access, were added as functions. Many functions that still exist in PHP today are part of that lineage: str_replace(); array_map(); json_encode(); file_get_contents(); mb_strlen(); mysqli_connect(); array_filter(); preg_match(); htmlspecialchars(); As you can see, many of them use snake_case . A technical note: why snake_case was likely natural PHP's implementation is written in C. The core runtime is called the Zend Engine. What is the Zend Engine? The Zend Engine is the internal engine that parses and executes PHP code. It was developed by Andi Gutmans and Zeev Suraski and has been the execution foundation of PHP since PHP 3. In C and its standard library ecosystem, function names are traditionally lowercase and often use underscores, although not always. Examples include names such as strcpy , memcpy , and time . Many early PHP built-in functions were thin wrappers around C functions or C libraries, so it is reasonable to think that C naming culture influenced PHP's function names. I do not mean this as a claim that every PHP function directly follows C naming rules. I have not exhaustively verified that. It is better understood as a general tendency. But it is not completely consistent If the story ended here, we might say "PHP built-ins are all snake_case." But that would not be accurate. Standard classes in PHP often have camelCase or PascalCase-style method names: $reflectionClass->getName(); $reflectionMethod->getParameters(); $dateTime->setTimezone($timezone); What is Reflection? ReflectionClass andReflectionMethod are part of PHP's built-in Reflection API. Reflection lets a program inspect information about classes, methods, parameters, modifiers, and more at runtime. Frameworks and testing tools often use it internally. So we need to distinguish between "global function culture" and "standard class/method culture". That difference connects directly to the later spread of object-oriented PHP. What is OOP? OOP stands for object-oriented programming. It is a way of designing programs around classes, where data and behavior are grouped together as properties and methods. The idea that "class methods use camelCase" comes up repeatedly later in this article. The PHP manual also has a page called Userland Naming Guide. It states that function names should use underscores between words, and that both camelCase and PascalCase appear in class names. It also names strpos() as an example of an old naming mistake because it does not follow the recommended extension prefix rule. So if PHP naming feels inconsistent, you are not imagining it. The official manual itself acknowledges historical inconsistency. My summary for this section is: PHP's built-in functions look snake_case not because of a perfectly planned language design, but because early PHP grew out of practical C-based implementation culture. 3. PHP 3 and the spread of function-based web programming PHP 3 was released in June 1998 as the official successor to PHP/FI. Around this point, PHP development expanded from a personal project into a broader multi-person effort. Features were added rapidly through extension modules. What is an extension module? An extension adds functionality to PHP itself. For example, thecurl extension provides HTTP communication through the cURL library, and themysqli extension provides MySQL access. Many PHP built-in functions are grouped by extensions like these. During this period, practical web development needs such as database access, form handling, and session management drove PHP's growth. Functions were added as needed. There was not yet a strong centralized process for reviewing naming consistency. Functionality and usefulness came first; naming consistency came later, if at all. Once a name is public, changing it is hard Once a function name is public and widely used, it becomes difficult to change. This is a backward compatibility problem. What is backward compatibility? Backward compatibility, often abbreviated BC, means code written for an older version of software keeps working in newer versions. Renaming or removing a function can break every existing codebase that uses it, so many languages and frameworks treat public API names as something that should not be changed casually. PHP's old mysql_* functions, such as mysql_query , are a good example. They went through deprecation and were eventually removed, but that took a long time. This illustrates how hard it is to change names and APIs after they become widely used. I am