> I have seen functions that were over 60,000 lines long
replyThat can't possibly be from a serious person.
I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, so it wouldn't surprise me if people created ones as big as bluGill describes.
replyThe C was almost always written by EEs who learned that function calls were expensive and so they minimized their use of them (this was their stated rationale, not me guessing). What amused me was that every time I tackled one of those things I'd reduce the line count by 70-90%, and usually at least double performance, by using a bunch of small functions to encapsulate the repeated logic. Compilers inline well, and have for quite some time.
> I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran,
replyThat, spoken by Rutger Hauer.
Sadly it is serious and in production code. (I left there 15 years ago, I suspect it isn't in production anymore)
replyWorse, it was a giant switch, and the target system didn't have enough memory for all the code so there were different builds and the user would select which to load.
There was code like
case foo:
doSomething();
#ifdef build_two
doSomethingElse();
break;
case bar:
SomeThing();
#endif
MoreThings();
break;
I’m not sure the author knew what was happening. It seems like it worked like this and they left it at that.
replyWhile this was the worst example he constantly wrote code like that. He could write code like that with few bugs faster than any other programmer I've ever worked with could write code. Management changed between loving and hating him, they knew what his code cost, but they also knew they were getting results fast when that mattered.
replyManual inlining, like manual loop unrolling wants an explanation, why did you do this, why not let the compiler do it? If I see it with no explanation I am going to assume you don't know what you're doing.
reply