2

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
Engineer2021
  • 3,238
  • 5
  • 28
  • 32
  • 4
    It's a guideline, and an *arbitrary* one at that. SLOC guidelines always are (arbitrary, that is). – Robert Harvey Mar 30 '15 at 00:56
  • 3
    The idea that smaller source files might be easier to understand is based on some cognitive science that says that human beings only have so much "working memory" and that having to wrap your head around 100 lines of code is easier than having to wrap it around 10000. And yes I have seen single files with over 50,000 lines of code on them. The idea that 50,000 lines of code in a single file is arbitrarily bad seems silly to me. – RibaldEddie Mar 30 '15 at 01:30
  • 2
    Required reading: _Clean_ _code_ by Uncle Bob. – Martin Schröder Mar 30 '15 at 09:04
  • 2
    Have you asked some of those "older programmers" for the reason(s)? If you just started on the project, it might be more useful to learn from the experienced people than to "research online". – GraniteRobert Mar 30 '15 at 12:55
  • possible answers: a manager 10 years wanted everything printed. The compiler 10 years ago took forever to do a partial build with our 10k SLOC files, so we broke them all down into no more than 100 lines. That's just a guideline, if you look at Foo, you'll see 101 lines in that file. That's just a guideline, if you look at Bar, you'll see 500 lines in that file. Who told you that... oh, those guys, they're not the architect, I am - 101 lines is perfectly acceptable. And so on and so forth... –  Mar 30 '15 at 19:47

2 Answers2

5

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.

Jacob Sparre Andersen
  • 314
  • 1
  • 5
4

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.

John R. Strohm
  • 18,043
  • 5
  • 46
  • 56
  • 3
    Quite often the problem is that a single function of 10,000 lines gets turned into 100 functions of 100 lines each making the "turn a page" problem into a "turn to chapter 10, section 5, subsection 3a" - infinitely worse IMHO :) – gbjbaanb Mar 30 '15 at 15:12
  • I'm looking at a routine with over 400 lines right now--and I don't have a problem with it. It's a massive switch statement that parses a configuration file. Most of the lines assign a value into a variable, some have to parse out multiple parameters. Sure, I could replace much of it with a big table of parameters and routines but generally I consider such approaches harder to read. Such things are rare but there are no elegant answers to dispatchers. – Loren Pechtel Mar 30 '15 at 20:59