Paste code to count blank, comment and source lines the way cloc does, see the composition, and estimate effort with Basic COCOMO 81.
Nothing is uploaded; the counting runs in your browser. Up to 2,000 lines.
A small, experienced team on a familiar problem in a stable environment. Boehm notes that very few organic-mode projects have exceeded 50 KSLOC.
Every rule verified against cloc 2.10 on files in six languages. Where a rule is contestable, this table says so.
| Kind of line | Counts as | cloc agrees |
|---|---|---|
| A line with code and a trailing comment | Code, once | Yes |
| A blank line inside a block comment or docstring | Blank | Yes |
| A #! line at the top of a file | Code | Yes |
| #include, #define and other C/C++ directives | Code | Yes |
| A whole line that is nothing but a string literal | Comment in Python, code elsewhere | Yes |
The bands are powers of ten, chosen here for readability rather than taken from a standard. For a real reference point, SQLite publishes its own size: 155.8 KSLOC (155,800 SLOC), counted the same way this page counts.
| Band | SLOC |
|---|---|
| Tiny | up to 1,000 |
| Small | up to 10,000 |
| Medium | up to 100,000 |
| Large | up to 1,000,000 |
| Very large | up to 10,000,000 |
| Massive | above 10,000,000 |
Effort = a x (KSLOC)^b, from Boehm, Software Engineering Economics (1981). These are the Basic coefficients; the Intermediate model uses a different set plus fifteen cost drivers.
| Mode | a | b | When it applies |
|---|---|---|---|
| Organic | 2.4 | 1.05 | Small, experienced team; familiar problem |
| Semi-detached | 3.0 | 1.12 | Mixed experience; some novelty |
| Embedded | 3.6 | 1.20 | Tight constraints; moving requirements |
Line counts describe size, not value or quality. COCOMO 81 was calibrated on 63 projects in 1981; treat its effort, schedule and cost figures as an order-of-magnitude starting point for discussion, never as a plan or a quote.
You might also find these calculators useful
Paste your code and get its cyclomatic complexity, function by function
Coverage by criterion, checked against requirements we can cite
Paste code, get its time and space Big-O with the derivation
Measure DevOps performance with four key metrics
Paste a file and this page counts it the way cloc, scc and sloccount do: blank lines, comment lines and source lines of code, with every convention stated so you can check the numbers rather than trust them. If you already have counts from a tool, switch modes and type them in. Either way you also get a Basic COCOMO 81 effort estimate, with the development mode as your choice rather than an assumption.
SLOC — source lines of code — is a count of the lines in a file that carry code, excluding blank lines and comments. It is a size measure, not a quality measure. Two counts of the same file disagree mainly because the counting rules differ, which is why SEI's counting framework treats a stated checklist as part of the measurement, and why this page lists its rules. Physical SLOC counts lines; logical SLOC counts statements, so a single physical line holding three statements counts once physically and three times logically. There is no fixed ratio between the two.
SLOC from a file's physical lines
Count what is actually there before estimating a migration or a rewrite, and separate hand-written code from generated files and vendored dependencies.
Run your SLOC figure through COCOMO in all three modes. If the spread is wider than the estimate you were given, the estimate depends on assumptions nobody has written down.
Compare comment ratios across modules to find the files that carry non-obvious logic with no explanation attached.
Publish a line count with the counting rules beside it, the way SQLite publishes its 155.8 KSLOC, so the figure can be reproduced.
COCOMO, function-point conversions and most parametric estimators take size in KSLOC. Without a size figure counted by a stated rule, the estimate has no anchor.
The share of documented lines that are comments tells you where a codebase sits between self-explanatory and unexplained — and flags files where the comments are commented-out code.
"Large" is not a size. Knowing a codebase is 40,000 SLOC rather than 400,000 changes onboarding, review load and how many people can hold it in their heads.
A line count only means something alongside the rules that produced it. Matching a reference tool's conventions is what makes your number comparable with anyone else's.
For a single file, paste it above. For a whole repository, run a directory-aware counter such as cloc, scc or tokei — this page counts one pasted file at a time, up to 2,000 lines, and matches cloc's per-line conventions so the two agree. If you already have a tool's output, switch to "I have the counts" and enter its blank, comment and code columns.
A line that carries at least one code character after comments are removed. Blank lines and lines that are purely commentary do not count. A line holding both code and a trailing comment counts once, as code, so the three classes always add up to the physical line count.
No. It counts once, as code. This page also reports how many such lines there were, so you can see how much of the file mixes the two — that number is a subset of the code count, not an extra class.
Physical SLOC counts lines; logical SLOC counts statements. A line holding three statements separated by semicolons is one physical line and three logical ones, and a statement wrapped over four lines is the reverse. This page counts physical SLOC. There is no fixed conversion between the two — it depends entirely on language and formatting style, so any single multiplier would be invented.
The usual reason is a different language being assumed, since comment markers differ. Check the detected-language badge and set it manually if needed. Beyond that, tools genuinely differ on edge cases: whether a shebang is code, whether a docstring is a comment, and how string literals occupying a whole line are treated. This page's rules are listed in the conventions table, each marked with whether cloc agrees.
Divide by 1,000. 12,500 SLOC is 12.5 KSLOC. COCOMO's original papers call the same quantity KDSI, thousands of delivered source instructions. The three names refer to the same measure; what varies between studies is the counting rule behind them, not the arithmetic.
No. Line count measures size, so it tells you how much there is to read, review and maintain — a cost, not an achievement. The same feature delivered in fewer lines is usually the better outcome. This is exactly why line count is a poor productivity metric and a reasonable size metric.
Basic COCOMO 81 was calibrated on 63 projects in 1981, before the tooling, languages and delivery practices most teams now use. Treat it as an order-of-magnitude check rather than a plan: useful for asking why an estimate is five times the model, not for committing to a date. Its own author replaced it with COCOMO II, which needs many more inputs than a line count.