LeetCode-Go: ten topics marked finished, ten not, and a cobra CLI that submits your answers

The topic list marks ten subjects finished and ten unfinished

The data structures section in the README carries a legend that is unusual for a solutions repository: topics marked with a check mark have all their problems completed, and those without the mark still have problems left to solve.

Ten are marked. Two Pointers, Linked List, Stack, Backtracking, Sort, Bit Manipulation, Union Find, Sliding Window, Segment Tree and Binary Indexed Tree.

Ten are not. Array, String, Tree, Dynamic programming, Depth First Search, Breadth First Search, Binary Search, Math and Hash Table, plus the unnamed remainder of the list.

That single convention is the most useful thing in the README, because it converts an apparently exhaustive repository into a map you can navigate. If you want to see how someone writes a segment tree in idiomatic Go, the check mark says the set is complete. If you are looking for tree problems, the absence of the mark tells you the coverage is partial before you have opened a file. Most collections of this kind present a directory listing and leave you to guess.

The data structures half is a library, not a problem set

The two tables below the topic list are not problem indexes. They enumerate variants of a data structure, and the breadth is what a textbook would cover.

The structures table runs from a sequential list and a singly linked list through to a hash table with its hash functions and collision resolution, a stack and a queue, string matching with KMP, finite-state automatons, Boyer-Moore, a combined BM-KMP and brute force, a tree with binary trees, union-find and Huffman, an array-based heap with max-heap, min-heap, a min-max heap, a double-ended heap and a d-ary heap, a tree-based heap with leftist, skew, binomial, Fibonacci and pairing heaps, and a search column that lists a skip list, AVL, B-tree, B+ tree, B* tree, AA tree, red-black, splay, trie and R-tree among others.

In the repository that lives in a structures/ directory, and the go.mod wires it into the module with a local replace directive, so it is importable as its own package rather than being copy-paste. For most engineers that is the more reusable half of this repository: a hand-written red-black tree or a KMP matcher in a consistent style is worth more than the two hundredth permutation problem.

Four local replace directives make this a multi-module project

The go.mod is small and does something worth understanding. The module is github.com/halfrost/LeetCode-Go and it declares go 1.19, and then four replace directives point at local directories: the structures package, the template package, and the ctl/util and ctl/models packages, each replaced with a relative path.

The corresponding require lines still carry pseudo-versions dated 2022-09-10, which is what a replace directive looks like when the upstream module existed before the code moved in-tree. The practical effect is that the code you read is the code that builds, with no network fetch for the parts that matter, and the stale-looking versions are a fossil of how the repository was assembled.

The other dependencies are equally few. BurntSushi/toml for configuration, mozillazg/request as an HTTP client, and spf13/cobra for the command line, with pflag and mousetrap arriving as its indirect dependencies. A solutions repository that carries a TOML parser, an HTTP client and a CLI framework is not just a folder of files, and the next section is what that tool is for.

ctl/ submits to LeetCode, which is why there is an HTTP client

A cobra-based command line tool with an HTTP client and a TOML configuration file is not something you need to read a solution, but it is what the repository was built around. The ctl/ directory at the root holds it, split into a util package and a models package, both wired in locally by the replace directives.

That combination answers a practical question. LeetCode problems are graded on submission, so a serious run of several hundred problems involves writing the answer, running it against the judge, reading the result, and moving on. Doing that by hand for hundreds of problems is the kind of tedium that stops a collection at forty entries, and a repository with this many solutions has clearly automated part of it.

The two development dependencies of that directory, git2-equivalent local paths aside, are the two I would read first if you wanted to extend the tool: the models package is where a problem and its answer are shaped, and the util package is where the request and the response are handled. The .nomedia and .gitignore entries at the root, plus a backups/ directory and a Remote Link script of the kind used to point a tool at a local checkout rather than a hosted copy, all point the same way.

The release number belongs to the book, not to the Go module

The three most recent releases are 1.7.97, titled as the LeetCode Cookbook version 1.7.97, published on 2026-06-28; 1.7.0 from 2021-06-20; and 1.6.6 from 2021-02-15.

That sequence explains itself. A release is a book edition, and the edition number is the version. The gap between 1.6.6 in February 2021 and 1.7.0 in June 2021, and then to 1.7.97 in June 2026, is the gap between book editions rather than between code releases. The last push to the repository was 2026-09-11, so the code is moving; it just does not get its own tag.

The root confirms it. There is a file called PDF v1.7.97.md, which is the markdown source for the offline PDF edition, sitting beside the README files. So if you are pinning a dependency on this repository, you are pinning a book edition, and if you are following the book's revision history, the tags are the thing to watch.

Coverage is a checked-in file, not only a badge

The repository description makes two claims in the same breath as the solutions themselves: 100% test coverage, and a runtime that beats 100% of submissions. Those are the project's own numbers, and the place to check them is in the repository rather than in the description.

There is a coverage.txt checked in at the root. There is a test workflow in .github/, a Codecov badge, a Go Report Card badge, a deploy workflow, and a gotest.sh script in the root that is the local counterpart of the CI test run. A .travis.yml is present as well, from the earlier CI era.

So the claim is checkable, and a checked-in coverage file is more useful than a badge for a specific purpose: you can diff it between two commits without running anything, which tells you whether a new problem arrived with a test or without one. What a checked-in file cannot do is prove the claim is current, because it is a snapshot of one run at one moment. If the distinction matters to you, run gotest.sh and read the result it produces.

One style guide across a few hundred files is the actual contribution

The README says the code style strictly follows the Google Golang Style Guide, and links the review comments document that the Go project publishes. That is the claim that makes the repository worth reading rather than merely copying from, because a few hundred algorithm files in one author's idiom is a small body of work with a consistent shape: the same package layout, the same test file convention, the same naming.

The rest of the tree supports that. There is a template/ directory, which is almost certainly the skeleton a new solution is copied from, a topic/ directory for per-topic indexes, note/ for the written notes that end up in the book, website/ for the site that serves the online edition, and a .vscode/ directory for editor settings. Two READMEs, one English and one Chinese, sit beside a README_old.md.

The cost of consistency is worth stating too. A strict house style is not always the style a given project would choose, and a solution written to a review guide is a solution written to be read rather than to be dropped into your codebase unchanged. Read it for the shape, then write it your way.

Editorial conclusion

Use LeetCode-Go to read a few hundred algorithms written in one consistent Go style, and to borrow the structures/ implementations for trees, heaps and string matching. Do not treat it as a curriculum with a finish line, because the topic table is the project's own admission that array, string, tree, dynamic programming, depth first search, breadth first search, binary search, math and hash table problems are still unfinished. Before you rely on anything here: run gotest.sh rather than assuming a file is correct, read coverage.txt if you want to see the project's own snapshot of what is exercised, and remember that a release tag such as 1.7.97 refers to a cookbook edition published on 2026-06-28, not to a version of the Go module, whose go.mod still declares go 1.19.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes