我也是这种感觉：想不出什么场合，一个或者一组算法，在指定一个人完成的情况下，需要超过一万行代码。
TeX 原始版也就一万多行类似于 Pascal 的代码，其中估计百分之七十都是注释，至少百分之五十。
当然有一些东西注定是要堆代码的，比如龙芯或者 x86 的编译器后端，但这种东西一来不可能一个人写，二来其中有不少平行的逻辑，之间天生解偶，所以可以分开考虑，第三则是这种 complexity 不是问题内源的，而且堆砌出来靠数量达到的复杂度，这种就可以靠堆 man year 来克服。而有些问题是 intrinsic 的复杂，只靠堆时间和代码没法解决。

【 在 xiaoju 的大作中提到: 】
:
: 我手写的最长代码是在中学，其次是大学，工作后没有写过单一目的特别长的代码，也想不到什么场合这么写是合理选择
:
: 当然见过很多非常长的代码，不过这类代码大都有严重问题
:

#发自zSMTH@Moto Z3 Play
--
FROM 188.67.236.*

巧了，我20年前也做过大型编译器，代码没仔细数过，前端+后端再加上算法库，支持编译模式和解释两种模式，支持内存动态链接，支持复杂事件状态分析，支持基于状态的字符串流检测，几十万行代码应该有的，几千个测试用例保证程序的正确性。。。

【 在 philbloo 的大作中提到: 】
: 这一百多层的楼里 比我老的可能不多。其实程序员内部也是隔行如隔山，谁强谁弱也说不太清楚。我做的比较偏门，compiler, cryptography, simulation, arch, 这些领域里的名词和概念，有些你可能还得查一下才知道是什么，更别说理解算法了。
:
: #发自zSMTH@Moto Z3 Play
--
修改:siegfried415 FROM 175.169.220.*
FROM 175.169.220.*

C工程，一个文件超过千行很常见。
一个工程超过万行也很常见。
当然也有一些比较变态的比如sqlite3.c一个工程一个文件接近13万行。

【 在 philbloo 的大作中提到: 】
:
: 一个人，任何语言。不一定要是产品，proof of concept 和 demo 以及一个模块都算。我没写过超过一万行的，我感觉达到五千行以后就很难控制了，会开始出现难以修复的 bug ，代码质量开始下降，人开始失去耐心，并开始忘记自己写过的代码。
: #发自zSMTH@Moto Z3 Play

#发自zSMTH@Note 8 Pro暖手宝
--
FROM 36.45.172.*

大佬，求问下数据流分析。有没有什么推荐的书目或者paper可以看？  有个类似编译后端分析问题。 SQL进行语法规则变异，生成一组新的SQLs。 对SQL语法解析树，用训练库的子树进行替换。  涉及到表列名的依赖分析 和实例化填充，复杂情况还要考虑子查询。


【 在 siegfried415 的大作中提到: 】
: 巧了，我20年前也做过大型编译器，代码没仔细数过，前端+后端再加上算法库，支持编译模式和解释两种模式，支持内存动态链接，支持复杂事件状态分析，支持基于状态的字符串流检测，几十万行代码应该有的，几千个测试用例保证程序的正确性。。。
:
--
修改:saynothing FROM 112.17.236.*
FROM 112.17.236.*

啊？你确定你做的是编译器？事件状态分析？字符串流检测？这都啥？能翻译成英语吗？我是没见过编译器论文提到这些东西的。

还有内存动态链接？那是 loader 啊，跟编译器有毛关系？

【 在 siegfried415 的大作中提到: 】
:
: 巧了，我20年前也做过大型编译器，代码没仔细数过，前端+后端再加上算法库，支持编译模式和解释两种模式，支持内存动态链接，支持复杂事件状态分析，支持基于状态的字符串流检测，几十万行代码应该有的，几千个测试用例保证程序的正确性。。。
:
: 【 在 philbloo 的大作中提到: 】
: : 这一百多层的楼里 比我老的可能不多。其实程序员内部也是隔行如隔山，谁强谁弱也说不太清楚。我做的比较偏门，compiler, cryptography, simulation, arch, 这些领域里的名词和概念，有些你可能还得查一下才知道是什么，更别说理解算法了。

#发自zSMTH@Moto Z3 Play
--
FROM 188.67.236.*