drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2025-04-01 13:52:42 +02:00
parent 651f779374
commit 2275f9c44d
11 changed files with 2044 additions and 1945 deletions
Download patch file Download diff file Expand all files Collapse all files

13
loc.md
View file

@ -1,12 +1,13 @@
# Lines of Code
Lines of code (LOC, KLOC = 10K LOC, MLOC = 1M LOC etc., also SLOC = source LOC) is a [metric](metric.md) of [software](sw.md) [complexity](complexity.md) that simply counts the number of lines of program's [source code](source_code.md). It is by no means a perfect measure but despite some [soyboys](soydev.md) shitting on it it's actually pretty good, especially when using only one language ([C](c.md)) with consistent [formatting style](code_formatting.md).
Lines of code (LOC, KLOC = 10K LOC, MLOC = 1M LOC etc., also SLOC = source LOC) is a [metric](metric.md) of [software](sw.md) [complexity](complexity.md) that simply counts the number of lines of program's [source code](source_code.md). It is by no means a perfect measure but despite some [soyboys](soydev.md) shitting on it it's actually pretty good, especially when using only one language ([C](c.md)) with consistent [formatting style](code_formatting.md). However it must also be used well -- here are the main caveats:
Of course the metric becomes [shitty](shit.md) when you have a project in 20 [programming languages](programming_language.md) written by 100 pajeets out of which every one formats code differently. Also when you use it as a [productivity](productivity_cult.md) measure at [work](work.md) then you're guaranteed your devs are gonna just shit our as much meaningless code as possible in which case the measure fails again. Fortunately, at [LRS](lrs.md) we don't have such problems :)
- **[Logarithmic](log.md) scale should be used**, i.e. rather than exact line count we should sort into categories such as: under 10 LOC, under 100 LOC, under 1000 LOC and so on.
- When you use it as a [productivity](productivity_cult.md) measure at [work](work.md), you're guaranteed your devs are gonna just shit our as much meaningless code as possible in which case the measure fails again. Here also the logarithmic scale doesn't make much sense, so basically using it as a performance measure just sucks. Fortunately, at [LRS](lrs.md) we don't have such problems :)
- Of course it also becomes [shitty](shit.md) when you have a project in 20 [programming languages](programming_language.md) written by 100 pajeets out of which every one formats code differently.
When counting lines, we need to define what sort of lines we count. We can either count:
Of course it may also be necessary to define what a "line of code" means. Usually we distinguish **raw lines** (every single one) and **logical lines** (only those that "matter", may exclude comments and empty lines). We may also have to decide if we count lines of [libraries](library.md) we use etc.
- raw (physical) lines: every single one
- lines that actually "matter" (*logical* lines), e.g. excluding comments, blank lines etc.
A comfy tool for counting lines is [`cloc`](cloc.md), but you can also just use `wc -l` to count raw lines.
A comfy tool for counting lines is [`cloc`](cloc.md), but you can also just use `wc -l` to count raw lines.
Here are (sometimes very) approximate line counts for some programs written (mainly) in [C](c.md), in ascending order: [hello world](hello_world.md) (~5), [brainfuck](brainfuck.md) interpreter (~50), [Fairy-Max](fairy_max.md) chess (~1000), [raycastlib](raycastlib.md) (~2000), [dwm](dwm.md) (~2500), [SAF](saf.md) (~5000), [Anarch](anarch.md) (~15000), [tcc](tcc.md) (~25000), [Lua](lua.md) (~30000), [Doom](doom.md) (~35000), [Quake](quake.md) (~100000), [Pokemon](pokemon.md) Emerald (~500000), [OpenBSD](openbsd.md) (~10000000), [Linux](linux.md) (~30000000), [Windows](windows.md) XP (~40000000).