cloc

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

Languages & Compilers

Explore on GitHub Read 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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 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.

* 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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	4	1	3
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	3	0	3
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	2	0	2
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	0	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	4	0	4
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	3	1	2
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	6	1	5
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	7	1	6
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	7	1	6
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	0	1

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

2 sources

justinsaccount·May 1, 2018

> It appears there are over 20k lines of Go code after excluding vendor libraries and the example and contrib directories (arguably, contrib should've been included). close.. $ find -name '*.go'|grep -v ./vendor|xargs wc -l|sort -n|tail 507 ./test/e2e/alertmanager_test.go 540 ./pkg/client/monitoring/v1/types.go 562 ./pkg/alertmanager/operator.go 643 ./pkg/prometheus/statefulset.go 719 ./pkg/prometheus/promcfg.go 760 ./test/e2e/prometheus_test.go 835 ./pkg/client/monitoring/v1/zz_generated.deepcopy.go 1152 ./pkg/prometheus/operator.go 11410 ./pkg/client/monitoring/v1/openapi_generated.go 24526 total Deleting the auto generate api files and ignoring test/ gives ------------------------------------------------------------------------------- Language files blank

Read the rest

comment code ------------------------------------------------------------------------------- JSON 9 0 0 6276 Go 31 1020 1065 6028 which is quite a bit off from 20k. > I dunno, it just feels a little disingenuous, to me, to say that something that involves this much code is just a "packaging method" for a normal application. What is disingenuous is to call the prometheus operator, that deploys an entire monitoring stack a "normal application" The operator sets up monitoring on all the nodes, runs all the server components including configuring grafana and setting up dashboards. Meanwhile, $ cloc puppet-prometheus-5.0.0 puppet-grafana-4.2.0 192 text files. 157 unique files. 48 files ignored. github.com/AlDanial/cloc v 1.76 T=1.09 s (131.9 files/s, 10534.0 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- Ruby 43 425 108 2477 Puppet 32 132 1747 2280 Markdown 6 494 0 1201 ERB 20 105 0 925 YAML 35 0 200 459 JSON 4 0 0 329 Bourne Shell 2 28 130 198 Bourne Again Shell 2 28 56 176 -------------------------------------------------------------------------------- SUM: 144 1212 2241 8045 -------------------------------------------------------------------------------- Which is that large and doesn't do ANY of the things that the prometheus operator does. > I believe this is the kind of thing people actually want. Highly efficient, thin "VMs" that are easy to manage and run as independent systems without requiring the resource commitment. Or, people want to use k8s so they can run entire clusters of machines as a single consistent system and take advantage of things like rolling deployments and self healing applications.

In Operator Framework: Building Apps on Kubernetes

cookiecaper·May 1, 2018

First, I don't think anyone notices or cares when I post specifically, so it's hard to really feel like my "general opinion" is well-known enough to not talk about it anymore. I'm no Joel Spolsky over here! Second, I feel like it's valid to point out that Operators are not really just a method of "packaging", in a post that tries to make it sound like Operators are just a small bit of YAML or metadata. You're writing real, non-trivial Go code that tells Kubernetes explicitly how to deploy and manage the lifecycles of specific types of applications. At least until now with the "Operator Framework", there wasn't really even anything that firmly defined an Operator as an Operator; it's just what some people called their Go code that manipulated k8s's object handling and lifecycle internals. But, if you insist, here's one operator I've worked

Read the rest

with: https://github.com/coreos/prometheus-operator . This is from CoreOS itself. Here's a patch I submitted about a year ago: https://github.com/coreos/prometheus-operator/pull/289 . This required updating the way the software handled HTTP response codes in one of its "watcher" daemons (because all packaging methods need those, right?), and fixing the order of operations in the bootstrap scripts. Some more general info about this repo: $ du -sh prometheus-operator/.git 51M prometheus-operator/.git The repo size is 51M. $ git rev-list --count master 1716 There have been almost 2000 commits. $ cloc --vcs=git --exclude-dir vendor,example,contrib . 290 text files. 278 unique files. 121 files ignored. github.com/AlDanial/cloc v 1.74 T=0.82 s (295.4 files/s, 48117.2 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Go 50 1581 1392 20622 JSON 9 0 0 6276 YAML 132 260 885 4164 Markdown 30 792 0 2957 Bourne Shell 17 65 58 257 make 1 34 2 91 Python 1 10 5 40 TOML 1 11 20 30 Dockerfile 2 8 0 27 ------------------------------------------------------------------------------- SUM: 243 2761 2362 34464 ------------------------------------------------------------------------------- It appears there are over 20k lines of Go code after excluding vendor libraries and the example and contrib directories (arguably, contrib should've been included). I dunno, it just feels a little disingenuous, to me, to say that something that involves this much code is just a "packaging method" for a normal application. "Sure, just write an operator to package that up" like it's comparable to a package.json manifest or something. It's not! You need custom daemons that watch files to make sure that your k8s deployment stays in sync, and then you need to exert very meticulous and specific control over Kubernetes' behavior to make things work well. I think it's demonstrative that it takes north of 20k lines of Go code to package an application for deployment on Kubernetes. What do you think? ------------- EDIT: And one clarification: my opinion on containers as such is probably not well-known, since you're conflating it with my opinion on Kubernetes. I like containers conceptually (who wouldn't?) and I run several of them through LXC: NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED axxxx-dev STOPPED 0 - - - false gentoo-encoder STOPPED 0 - - - false jeff-arch-base-lxc STOPPED 0 - - - false jeff-crypto RUNNING 0 - xxx.xxx.xx.xxx - false jeff-ffmpeg STOPPED 0 - - - false jeff-netsec STOPPED 0 - - - false jeff-ocr STOPPED 0 - - - false localtorrents-lxc RUNNING 0 - xxx.xxx.xx.xxx - false nim-dev STOPPED 0 - - - false plex-2018 RUNNING 1 - xxx.xxx.xxx.xxx - true unifi STOPPED 0 - - - true I believe this is the kind of thing people actually want. Highly efficient, thin "VMs" that are easy to manage and run as independent systems without requiring the resource commitment. There is a good place for Kubernetes in probably about 1% of deployments where it's used. Most other people are just trying to run something like LXC, but they're confused because everyone who is critical of k8s drops to -4 and gets HN's mods after them. :)

In Operator Framework: Building Apps on Kubernetes