Source file shouldn't be more than 100 SLOC

Question

I just started working on a baseline that is rooted in Ada. Many of the older Ada programmers insist that the source files shouldn't be more than 100 SLOC. I researched this online and I have not found any source to this statement. Is this a guideline or a rooted in sound software engineer principles? I have been a software engineer for 13 years and never heard of this until now. They insist that code in these smaller source files are easier to understand but it seems to me that there would be tons of small source files.

Answer 1

The closest I have ever come to a guideline similar to that you ideally should be able to see the full source of a subprogram on the display at the same time.

I am pretty sure the "Ada 95 Quality and Style Guide", which is the authoritative style guide for modern Ada programming, does not contain anything like this limitation.

Answer 2

In over 40 years in this crazy racket, as a student and as a professional, I have basically seen one (1) routine that NEEDED to be more than about one printed page (about 60 lines) long. I've seen some really ugly state machines that had a LOT of states (I think the record is 35), that really couldn't be factored cleanly, but state machines are a special case.

That's not to say I haven't seen a lot of routines that WERE more than one printed page long. Average and below-average (by definition, half of all programmers are below average!) C and C++ programmers spout 500 line stream-of-consciousness spews at the drop of a keystroke, and somehow never manage to go back and clean them up. Cut-and-paste coding is the norm, with the same dozen lines appearing in half-a-dozen places, instead of being cut into a subprocedure and called (or macro-expanded, in the RARE! case where subroutine call overhead is too high).

For that matter, I've written a few of them, under schedule pressure.

There is a HUGE body of knowledge, going back to before I started, showing conclusively that programmer comprehension drops off dramatically the moment a programmer has to "turn a page". Start with Weinberg's "Psychology of Computer Programming". At 100 SLOC, you are going to turn a listing page at least once. You are going to scroll your editor two or three times, depending on screen size. (I once adopted a fairly quirky editor for a task, JUST because it supported 50-line VGA mode, for working on a certain very messy piece of code.)

I have seen considerable evidence that enforcing modularity makes a big difference. Traditional FORTH implementations force modularization and refactoring, as they make it IMPOSSIBLE to write long stream-of-consciousness code spews. FORTH programmers are FORCED to break things into easily-digestible chunks, and it seems to make a big difference. (Note: Elizabeth Rather, the second FORTH programmer in history, disagrees with me on this.)

People occasionally ask whether modern IDEs that allow code to be "folded" (blocks collapsed) would get around this human limitation. I have seen no studies, and I would be suspicious of any study that purported to address it: I'd want to know how many people of what kinds of backgrounds were in the study. I have also actually never seen such an IDE in actual use. (I've only heard of one, the old Rational R1000 Ada Development System, and it went to the dinosaur graveyard a long time ago.)

"100 SLOC" is probably a guideline, but it has the flavor of a guideline written in the blood of countless software engineers who had to debug 1000-SLOC spews. (Been there, done that, didn't WANT the T-shirt.) You probably want to follow it, if only to keep the greybeards from screaming "GET OFF MY LAWN!" at you.