# PHPAlgorithms: a Composer pack of textbook algorithms for PHP

> doganoo/PHPAlgorithms is a PHP implementation of common algorithms and data structures arranged around the chapters of Cracking the Coding Interview, installed with Composer and organised as a plain source package with PHPUnit and PHPStan configs.

**doganoo/PHPAlgorithms** — A collection of common algorithms implemented in PHP. The collection is based on "Cracking the Coding Interview" by Gayle Laakmann McDowell

- Repository: https://github.com/doganoo/PHPAlgorithms
- Stars: 946 · Forks: 90
- Language: PHP
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/doganoo-phpalgorithms

## A study collection organised around one book

PHPAlgorithms is a collection of common algorithms implemented in PHP, and the organising idea is stated in the repository description: the collection is based on Cracking the Coding Interview by Gayle Laakmann McDowell. The topic tags on the repository carry the same idea, listing cracking-the-coding-interview, datastructures, lists, maps and algorithm alongside the language tags.

That framing tells you what to expect from the code. The classes exist to make a well known problem concrete, not to model a domain. The README makes the argument for combining the two halves of the toolkit, algorithms and data structures, and ties them to the idea that programs come out of that combination.

For a PHP developer who keeps rewriting a binary tree, a linked list or a graph traversal in each new project, the package removes the repetition. For a team that has already modelled these structures properly for its own domain, the value drops sharply, because the package's shapes are shaped by a book rather than by your constraints. Nothing in the tree code, for example, is tied to your own invariants, since the package has no notion of them.

The maintainer is a single named person, Doğan Uçar, and the README asks contributors to read a best practices page and a contribution guide before opening a pull request. That is a reasonable, small project, and it is worth judging on that basis.

## Namespaces reveal the taxonomy the package exposes

The repository layout is a plain PHP library: a src directory for the code, a tests directory, a composer.json and composer.lock, a phpunit.xml and a phpstan.neon, plus contribution and pull request templates, a code of conduct file and a travis.yml.

The namespace of the example class tells you how the taxonomy is organised, and the path is more informative than the class list. The import in the README example is:

```php
use doganoo\PHPAlgorithms\Datastructure\Graph\Tree\BinaryTree;
```

Read that path from the right and the structure of the collection appears. There is a Datastructure grouping, inside it a Graph grouping, inside that a Tree grouping, and the concrete class at the end. Structures that would be considered graphs in an academic sense, such as trees, are filed under that umbrella, which tells you the author was working from the book's taxonomy of problems rather than from a database or application model.

The root namespace carries the vendor prefix and the package name, so every class you pull in is namespaced under doganoo\PHPAlgorithms. That matters for a codebase with a namespace convention of its own, because a fully qualified import like the one above is verbose enough that you will usually alias it.

## Installing with Composer and inserting the first values

The package is published on Packagist as doganoo/php-algorithms and the README gives a single Composer command for the install:

```bash
composer require doganoo/php-algorithms
```

That is the whole installation story. There is no configuration file to write, no service to register and no bootstrap step, because the package is a set of classes rather than a framework.

The first real use is the binary tree from the README, which inserts five values and then serialises the result:

```php
use doganoo\PHPAlgorithms\Datastructure\Graph\Tree\BinaryTree;

$binaryTree = new BinaryTree();
$binaryTree->insertValue(50);
$binaryTree->insertValue(25);
$binaryTree->insertValue(75);
$binaryTree->insertValue(10);
$binaryTree->insertValue(100);

echo json_encode($binaryTree);
```

The expected output in the README shows the shape you should see, with each node carrying a value and left and right children that are null at the leaves:

```php
{"nodes":{"value":50,"left":{"value":25,"left":{"value":10,"left":null,"right":null},"right":null},"right":{"value":75,"left":null,"right":{"value":100,"left":null,"right":null}}}}
```

Notice that the output is a single nodes object with nested left and right objects. A tree with a null child on either side is represented by that key being present and null, not by the key being absent. If you serialise the tree into an API response, that is the contract you inherit, and any client that assumes absent keys will see a difference.

## Static analysis and unit tests sit in the repository, CI sits on travis

The top level of the repository shows a project that takes its own quality tooling seriously: a phpstan.neon configuration for static analysis, a phpunit.xml for the test suite, a tests directory, and an .editorconfig. There is also a .github directory and a travis.yml, so the project has both GitHub configuration and a Travis configuration file.

For an adopter this matters in a specific way. The presence of phpstan.neon tells you the code is expected to pass static analysis at whatever level the configuration sets, which is a good sign for a package you will call with strict types in your own project. The presence of phpunit.xml tells you the behaviour is covered by tests you can run, and the tests directory is where the expected behaviour of each class is written down in a form you can read before relying on it.

What the repository does not tell you is equally relevant. The README does not say which PHP versions are supported, does not list performance characteristics for any structure, and does not document what happens when insertValue is called with a value that is already in the tree. If your use depends on duplicate handling or on a guarantee about ordering, you need to read the class source and the tests in the tests directory yourself. Nothing in the documentation settles those questions for you.

## Version 2.1.2 arrived three years after 2.1.1

The release history is short and uneven. Version 2.1.0 was published on 2022-05-25 with the note that it added fromIterable, version 2.1.1 on 2023-05-28 with the note that it contained smaller fixes, and version 2.1.2 on 2026-10-02. The last push was on 2026-10-02 as well, so the newest tag and the newest commit are the same day.

The gap between 2.1.1 and 2.1.2 is close to three years, and it coincides with a change of maintainer activity rather than a change in scope. That is the practical upgrade question for anyone depending on this package: the version number moved twice since 2022.

Licence terms are simple here. The licence field on the repository says MIT, and the README repeats MIT under its own heading, with a LICENSE file at the top level. MIT is permissive and short, so using the package inside a closed source product carries no copyleft obligation. That is a statement about the licence terms, not legal advice, and the practical risk sits elsewhere: the package carries a single maintainer, so availability and response time are informal rather than contracted.

The repository has no separate homepage beyond the repository itself, and the project description points to Packagist as the distribution point. The image in the README and the maintainer link are the only external references.

## When copying the code beats depending on the package

The realistic alternative to this package is not another library, it is writing the twenty lines yourself, or copying the implementation into your own namespace. For a data structure used in one place, that is often the better trade, and the difference in approach is worth spelling out.

The package approach gives you a class that matches the book's semantics, tested and analysed, with a version you can pin in composer.lock. It also gives you a dependency whose namespace taxonomy is shaped by the book, which you may have to work around in your own code, and whose behaviour on edge cases the documentation leaves open.

The copy approach gives you full control over semantics, including duplicate handling, ordering and error conditions, and it removes the dependency entirely. What it costs you is the maintenance of the code and the loss of the shared implementation when the package improves, for example when a version adds a helper like fromIterable.

The practical dividing line is the number of places you use the structure. One call site in an internal tool is a copy candidate. A shared library consumed by several applications, where consistency of behaviour across services matters, is a dependency candidate, provided you pin 2.1.2 and read the tests directory for the edge cases the README leaves out.

## Conclusion

PHPAlgorithms fits a PHP developer who wants working, named implementations of classic data structures rather than writing them again, and who is comfortable with a collection organised around a book rather than around a stable application API. It is the wrong dependency for a performance sensitive service, for a domain model with its own invariants, or for a team that needs a maintained version guarantee. Before adopting it, install version 2.1.2 with Composer, run the BinaryTree example, and read the namespace layout under src to confirm that the class names match what your code already expects.

## FAQ

### How do I install PHPAlgorithms?

The package is published on Packagist as doganoo/php-algorithms and the README gives a single Composer command, `composer require doganoo/php-algorithms`. There is no additional configuration or bootstrap step, because the package only ships classes.

### What is the BinaryTree class in PHPAlgorithms and how do I use it?

It lives in the namespace doganoo\PHPAlgorithms\Datastructure\Graph\Tree\BinaryTree. You create it, call insertValue for each item, and the README shows that json_encode on the instance produces a nested object of nodes with value, left and right keys.

### Which PHP version does PHPAlgorithms support?

The README does not state a supported PHP version, and the composer.json contents are not shown in the documentation. The repository topic tags include php7, but that is a tag rather than a stated compatibility promise, so check the composer.json in the repository before depending on it.

### Is PHPAlgorithms actively maintained?

The last push was on 2026-10-02, which is when version 2.1.2 was also published, so the code base is receiving work. The release cadence is uneven though, with version 2.1.1 dated 2023-05-28 and version 2.1.0 dated 2022-05-25.

### What licence is PHPAlgorithms released under?

MIT. The licence field on the repository says MIT and the README repeats it under its own License heading, with a LICENSE file at the top level of the project.

## Sources

- [doganoo/PHPAlgorithms on GitHub](https://github.com/doganoo/PHPAlgorithms)
- [Issues](https://github.com/doganoo/PHPAlgorithms/issues)
- [License: MIT](https://github.com/doganoo/PHPAlgorithms/blob/master/LICENSE)
- [README](https://github.com/doganoo/PHPAlgorithms/blob/master/README.md)
- [Releases](https://github.com/doganoo/PHPAlgorithms/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/doganoo-phpalgorithms