HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
AlDanial
cloc
Perl2016–2026
AlDanial / cloc

cloc

cloc counts blank lines, comment lines, and physical lines of source code in many programming languages.

Languages & Compilers
Explore on GitHubRead Hacker News discussions
34Distinct people
39Mentions
0Explicit recommenders
23.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

cloc counts blank lines, comment lines, and physical lines of source code in many programming languages.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year39 dated mentions

Observed mentions: 2016-04-18 20:21:59 UTC to 2026-01-07 21:52:30 UTC.

02462016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC413
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC303
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC615
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC716
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC716
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
cloc Count Lines of Code cloc counts blank lines, comment lines, and physical lines of source code in many programming languages. Latest release: v2.10 (July 4, 2026) cloc moved to GitHub in September 2015 after being hosted at http://cloc.sourceforge.net/ since August 2006. Quick Start Step 1: Install cloc (see Install from Github Releases and Install via package manager) or run cloc's docker image. The Windows executable has no requirements. The source version of cloc requires a Perl interpreter, and the Docker version of cloc requires a Docker installation. Step 2: Open a terminal (cmd.exe on Windows). Step 3: Invoke cloc to count your source files, directories, archives, or git commits. The executable name differs depending on whether you use the development source version (cloc), source for a released version (cloc-2.10.pl) or a Windows executable (cloc-2.10.exe). On this page, cloc is the generic term used to refer to any of these. Include Security has a YouTube video showing the steps in action. a file prompt> cloc hello.c 1 text file. 1 unique file. 0 files ignored. https://github.com/AlDanial/cloc v 1.65 T=0.04 s (28.3 files/s, 340.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 1 0 7 5 ------------------------------------------------------------------------------- a directory prompt> cloc gcc-5.2.0/gcc/c 16 text files. 15 unique files. 3 files ignored. https://github.com/AlDanial/cloc v 1.65 T=0.23 s (57.1 files/s, 188914.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 10 4680 6621 30812 C/C++ Header 3 99 286 496 ------------------------------------------------------------------------------- SUM: 13 4779 6907 31308 ------------------------------------------------------------------------------- an archive We'll pull cloc's source zip file from GitHub, then count the contents: prompt> wget https://github.com/AlDanial/cloc/archive/master.zip prompt> cloc master.zip https://github.com/AlDanial/cloc v 1.65 T=0.07 s (26.8 files/s, 141370.3 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Perl 2 725 1103 8713 ------------------------------------------------------------------------------- SUM: 2 725 1103 8713 ------------------------------------------------------------------------------- a git repository, using a specific commit This example uses code from PuDB, a fantastic Python debugger. prompt> git clone https://github.com/inducer/pudb.git prompt> cd pudb prompt> cloc 6be804e07a5db 48 text files. 41 unique files. 8 files ignored. github.com/AlDanial/cloc v 1.99 T=0.04 s (1054.9 files/s, 189646.8 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 28 1519 728 4659 reStructuredText 6 102 20 203 YAML 2 9 2 75 Bourne Shell 3 6 0 17 Text 1 0 0 11 make 1 4 6 10 ------------------------------------------------------------------------------- SUM: 41 1640 756 4975 ------------------------------------------------------------------------------- each subdirectory of a particular directory Say you have a directory with three different git-managed projects, Project0, Project1, and Project2. You can use your shell's looping capability to count the code in each. This example uses bash (scroll down for cmd.exe example): prompt> for d in ./*/ ; do (cd "$d" && echo "$d" && cloc --vcs git); done ./Project0/ 7 text files. 7 unique files. 1 file ignored. github.com/AlDanial/cloc v 1.71 T=0.02 s (390.2 files/s, 25687.6 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- D 4 61 32 251 Markdown 1 9 0 38 make 1 0 0 4 ------------------------------------------------------------------------------- SUM: 6 70 32 293 ------------------------------------------------------------------------------- ./Project1/ 7 text files. 7 unique files. 0 files ignored. github.com/AlDanial/cloc v 1.71 T=0.02 s (293.0 files/s, 52107.1 lines/s) ----------------------------
Read the full README on GitHub

What Hacker News says

39 sources
Kerrick·Jan 7, 2026
ratatui_ruby % git remote -v origin https://git.sr.ht/~kerrick/ratatui_ruby (fetch) origin https://git.sr.ht/~kerrick/ratatui_ruby (push) ratatui_ruby % git checkout v0.8.0 HEAD is now at dd3407a chore: release v0.8.0 ratatui_ruby % git log --reverse --format="%ci" | head -1 | read first; \ echo "First Commit: $first\nHEAD Commit: $(git show -s --format='%ci' HEAD --)" First Commit: 2025-12-22 00:40:22 -0600 HEAD Commit: 2026-01-05 08:57:58 -0600 ratatui_ruby % git log --numstat --pretty=tformat: | \ awk '$1 != "-" { \ if ($3 ~ /\./) { ext=$3; sub(/.*\./, "", ext) } else { ext="(no-ext)" } \ if (ext ~ /^(txt|ansi|lock)$/) next; \ add[ext]+=$1; rem[ext]+=$2 \ } \ END { for (e in add) print e, add[e], rem[e] }' | \ sort -k2 -nr | \ awk 'BEGIN { \ print "------------------------
Read the rest
---------------"; \ printf "%-12s %12s %12s\n", "EXT", "ADDED", "REMOVED"; \ print "---------------------------------------" \ } \ { \ sum_a += $2; sum_r += $3; \ printf "%-12s %12d %12d\n", $1, $2, $3 \ } \ END { \ print "---------------------------------------"; \ printf "%-12s %12d %12d\n", "SUM:", sum_a, sum_r; \ print "---------------------------------------" \ }' --------------------------------------- EXT ADDED REMOVED --------------------------------------- rb 51705 18913 md 20037 13167 rs 8576 3001 (no-ext) 4072 2157 rbs 2139 569 rake 1632 317 yml 1431 153 patch 894 894 erb 300 30 toml 118 39 gemspec 62 10 gitignore 27 4 css 22 0 yaml 18 2 ruby-version 1 1 png 0 0 gitkeep 0 0 --------------------------------------- SUM: 91034 39257 --------------------------------------- ratatui_ruby % cloc . 888 text files. 584 unique files. 341 files ignored. github.com/AlDanial/cloc v 2.06 T=0.26 s (2226.1 files/s, 209779.6 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- Ruby 305 4792 10413 20458 Markdown 60 1989 256 4741 Rust 32 645 530 4400 Text 168 523 0 4358 YAML 8 316 17 961 ERB 3 20 4 246 Bourne Again Shell 2 24 90 150 TOML 5 16 10 53 CSS 1 3 8 11 -------------------------------------------------------------------------------- SUM: 584 8328 11328 35378 --------------------------------------------------------------------------------
In Claude Code CLI was broken
bsnnkv·Oct 22, 2025
On another discussion forum I saw someone posted[1] the results of running shellcheck against the bash scripts that make up Omarchy: λ omarchy master Ɇ » shellcheck -f checkstyle bin/* **/*.sh | grep error | wc -l 451 λ omarchy master Ɇ » cloc . 662 text files. 473 unique files. 253 files ignored. github.com/AlDanial/cloc v 2.06 T=0.07 s (6645.0 files/s, 133055.1 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- Bourne Again Shell 125 704 319 3344 Bourne Shell 237 499 229 1952 C
Read the rest
SS 41 122 22 653 TOML 19 113 9 612 XML 3 6 12 437 Lua 12 0 0 151 INI 14 20 0 78 JSON 13 0 0 67 YAML 4 4 0 50 Text 2 0 0 36 JavaScript 1 1 0 20 Markdown 1 5 0 5 SVG 1 0 0 1 -------------------------------------------------------------------------------- SUM: 473 1474 591 7406 -------------------------------------------------------------------------------- [1]: https://lobste.rs/s/iuvukw/word_on_omarchy#c_slymk9
In A Word on Omarchy
ChrisMarshallNY·Jul 14, 2025
Nope. It's a "Me" thing. I write code that I want to see. I have fairly big files, and it makes it easy to scroll through, quickly. It also displays well, when compiling with docc or Jazzy. My comment/blank line-to-code ratio is about 50/50. Most of my comments are method/function/property headerdoc/docc labels. Here's the cloc on the middle project: github.com/AlDanial/cloc v 2.04 T=0.03 s (1319.9 files/s, 468842.4 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Swift 33 1737 4765 5220 ----------------------------------------------------------------------------
Read the rest
--- SUM: 33 1737 4765 5220 -------------------------------------------------------------------------------
In How I build software quickly
Tmpod·Jun 24, 2025
I tried starship a few years ago and found it too "extra" and sluggish. I'm sure it may have improved in this time, but I ended up sticking with the excellent Hydro[0], only for fish though. It's very minimal while having useful features: - exit codes, even for pipelines - git branch, status (displayed as a dot if your tree is dirty) and ahead/behind counts - command execution time (if above some configurable threshold) - truncated/minified $CWD, always maintaining the git root's name (I sometimes like it, sometimes don't; fortunately, it's very easy to change) - current vi-like mode (I don't use that) It's very fast and async (prompt repaints don't block your input or running commands), and totals 132 lines of fish (according to cloc[1]). It's also very customisable through variables, which can be declared as universal to instantly chang
Read the rest
e on all sessions you have open. If you're on fish and like this feature set, definitely give it a shot, or at least look at the code as a base for a bespoke prompt :P [0]: https://github.com/jorgebucaran/hydro [1]: https://github.com/AlDanial/cloc
In Starship: A minimal, fast, and customizable prompt for any shell
genericspammer·May 20, 2025Submission

Show HN: Plot lines of code over time in Git repositories

It's a small wrapper around cloc (https://github.com/AlDanial/cloc), which just provides a convenient way to plot lines of code over time in a Git repository. The script runs cloc on each commit in your current branch, starting from HEAD tracing back until the first commit. For large repositories with many commits, you can tell it to only count every n:th commit with the '--step' option to speed up processing. The way it works is quite sub-optimal, since every single file is counted in each commit, even if the file didn't change since last iteration. Might be a fun project later to find some nice optimizations, maybe by counting files one by one and keeping a dict of line count by file hash, or something along those lines. Maybe someone will find this script useful, maybe not, anyways happy to hear if someone has any thoughts :)
2 points · Open discussion
CuriouslyC·May 16, 2025
Not public on github, but here's the cloc for an easy 5k one day (10k is sweats). github.com/AlDanial/cloc v 2.04 T=0.05 s (666.3 files/s, 187924.3 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 24 1505 1968 5001 Markdown 4 37 0 121 Jinja Template 3 17 2 92 ------------------------------------------------------------------------------- SUM: 31 1559 1970 5214 ----------------------------------------------------
Read the rest
--------------------------- Note this project also has 199 test cases. Initial commit for cred: commit caff2ce26225542cd4ada8e15246c25176a4dc41 Author: redacted <redacted> Date: Thu May 15 11:32:45 2025 +0800 docs: Add README And when I say easy, I was playing the bass while working on this project for ~3 hours.
In After months of coding with LLMs, I'm going back to using my brain
derefr·Dec 1, 2024
> It's generally my view that from a bird's eye view LSMs are simpler than on-disk Btrees, largely because they are more composable and a lot more of their data is immutable. I dunno about this. On-disk B-trees can actually be pretty dang simple! Both conceptually and in implementation. In concept, for an on-disk B-tree "table", you've got: 1. one growable file, or a sequence of fixed-size split files, abstracted over into a "vector of pages" type that you can 1. find the base pointer of, 2. overwrite a full page of, or 3. extend; 2. a "metapage" type, that works like the world's most trivial filesystem: it owns a "freelist" of page numbers, and keeps a pointer to the live root of the B-tree; and it embeds its own hash, and a version number. 3. a mechanism for discovering/choosing the newest live+valid metapage, essentially making this tr
Read the rest
ivial "filesystem" into a trivial "journalling" filesystem. (in e.g. LMDB, you just have two metapages in pages 0 and 1, that are alternately written to, sort of like double-buffering; on DB open, the newer of the two by version is chosen if it's valid by hash; otherwise the older is used.) 4. a readers-writer lock (which doesn't need to be persisted to disk, because the on-disk file is never in a volatile/dirty state. You can just OS-advisory-lock the file — those locks disappear when the creator process dies, which is what you want here); 5. read-only transactions, that take a reader lock, discover the newest live metapage, dereference the B-tree root, and pass that pointer off to the user, letting them have at it, reading the B-tree arbitrarily as if it were an in-memory data structure; 6. read-write transactions, that take a writer lock, discover the newest live metapage, dereference the b-tree root, set up an in-memory dirtied pages map, and then let you read arbitrarily + write arbitrarily (with reads indirected through the dirtied-pages map, acting as an overlay); 7. Copy-on-Write updates to "clean" pages during rw txs, by cloning the clean page contents onto free[listed] pages, dirtying the clone with the update, and adding the dirty version of the page to the dirtied pages map, to overlay the original page; 8. a read-write tx commit op that "propagates" the changes from dirty pages, by Copy-on-Write rewriting the B-tree ancestors of the parent pages to point to the new dirty page numbers, until you derive a new B-tree root page — which you then create a new metapage for, fsync the file, and then write the metapage. (Note that this last bit means that a read-write transaction will effectively implicitly "roll back" on crash/power cut — the data is written before the "journal entry" for it, so if the "journal" doesn't make it to disk, then the data updates — including the updated freelist — are "lost". All a failed tx has done is update free pages.) Sure, that's eight things you need to implement. But none of them are complicated or unintuitive, the way that a "lock free concurrent skiplist" is. You could whiteboard any one of those abstractions above with a junior programmer, and they could probably figure out a basically-correct implementation just from the descriptions above. And that means that the implementations of on-disk B-trees are usually pretty short-and-sweet. LMDB, for example, is one C file (https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblm...) with ~8k of actual code (according to https://github.com/AlDanial/cloc). Postgres's durable B-tree implementation (https://github.com/postgres/postgres/tree/master/src/backend...) is 22kloc, and ~10kloc of actual code.
In Fine, I'll Play With Skiplists
James_K·Nov 13, 2024
/tmp/kibi % cloc . 98 text files. 89 unique files. 11 files ignored. github.com/AlDanial/cloc v 1.96 T=0.05 s (1936.6 files/s, 82405.1 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Rust 15 241 379 1480 Markdown 5 179 22 502 INI 50 3 20 388 YAML 10 36 21 281 XML 1 0 1 62 TOML
Read the rest
3 10 1 57 Bourne Shell 1 13 8 46 JSON 2 0 0 31 Dockerfile 1 2 0 3 SVG 1 0 0 1 ------------------------------------------------------------------------------- SUM: 89 484 452 2851 ------------------------------------------------------------------------------- I'm not sure if this counts as less than 1024.
In Kibi – A text editor in less than 1024 lines of code, written in Rust
boyter·Jul 29, 2024
More lines of code usually indicates more bugs so its not an entirely useless metric. Using it to gauge employee productivity is, since as the linked suggests some of the better programmers are able to remove code, which often reduces the potential for bugs. I personally find some use it in, if nothing else to identify which files probably need to be refactored as they are too large, or complex. Throw in some cyclomatic complexity and you are getting some useful information out the code counts. Counting lines of code is one metric though. Another I have seen thrown around is ULOC https://cmcenroe.me/2018/12/14/uloc.html where you count the number of unique lines of code, sort -u *.h *.c | wc -l Again another metric that potentially speaks to the health of a project. I personally wrote about this some time ago when someone asked why I
Read the rest
wrote a code counting project https://boyter.org/posts/why-count-lines-of-code/ and I liked the idea of ULOC so much I integrated it into the project as well. Clearly I am not alone in this though, hence there being so many code counters around (forgive me if I missed yours in the following list) and discussion around it. - [SLOCCount](https://www.dwheeler.com/sloccount/) the original sloc counter - [cloc](https://github.com/AlDanial/cloc), inspired by SLOCCount; implemented in Perl for portability - [gocloc](https://github.com/hhatto/gocloc) a sloc counter in Go inspired by tokei - [loc](https://github.com/cgag/loc) rust implementation similar to tokei but often faster - [loccount](https://gitlab.com/esr/loccount) Go implementation written and maintained by ESR - [ployglot](https://github.com/vmchale/polyglot) ATS sloc counter - [tokei](https://github.com/XAMPPRocky/tokei) fast, accurate and written in rust - [sloc](https://github.com/flosse/sloc) coffeescript code counter - [scc](https://github.com/boyter/scc) my own counter Incidentally the articles author confused me for a while using standard unix tools to count code, as I had them confused for David Wheeler who wrote the very first code counter that I know of sloccount.
In Counting Lines of Code
Bogdanp·Feb 7, 2024
In terms of code size, the repo is about 50/50 Racket and Swift: $ cloc FranzCocoa FranzCross core/ manual/ --include-lang=swift,racket 355 text files. 244 unique files. 419 files ignored. github.com/AlDanial/cloc v 1.98 T=0.06 s (2511.1 files/s, 383637.1 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Racket 91 1235 79 9968 Swift 53 1148 132 9438 ------------------------------------------------------------------------------- SUM: 144 2383 211
Read the rest
19406 ------------------------------------------------------------------------------- But, if I include all the supporting Racket libraries I built for the app, the ratio changes to about 4/1 in favor of Racket: $ cloc FranzCocoa FranzCross core/ manual/ <more paths> --include-lang=swift,racket 1644 text files. 996 unique files. 3334 files ignored. github.com/AlDanial/cloc v 1.98 T=0.35 s (1871.6 files/s, 168111.5 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Racket 598 5535 356 41295 Swift 65 1316 272 10779 ------------------------------------------------------------------------------- SUM: 663 6851 628 52074 -------------------------------------------------------------------------------
In Show HN: Franz – A desktop client for Apache Kafka

Showing the 15 most recent of 39 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.