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-03 21:49:43 +02:00
parent 490ffab10e
commit ee83d8a6b6
38 changed files with 2053 additions and 2030 deletions
Download patch file Download diff file Expand all files Collapse all files

8
loc.md
View file

@ -1,12 +1,12 @@
# 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). However it must also be used well -- here are the main caveats:
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](number.md) of lines of program's [source code](source_code.md). It is by no means a [flawless](perfect.md) 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:
- **[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 you use it as a [productivity](productivity_cult.md) measure at [work](work.md), you're guaranteed your slave peasants are gonna just shit out as much meaningless code as possible in which case the measure crumbles under a spectacular fountain of code diarrhea and 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. This we also do not practice.
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.
Of course it may also be necessary to define what a "line of code" means exactly. Usually we distinguish **raw lines** (every single one) and **logical lines** (only those that "matter", may exclude comments and empty lines). Does a long line with a line break count as a single line or two? Do we include line count of [libraries](library.md) we use? What if instead of lines we rather measured source code file size? Or programming language token count? Just make sure you know what you're measuring and why.
A comfy tool for counting lines is [`cloc`](cloc.md), but you can also just use `wc -l` to count raw lines.