> > To me, a 1000-line module is a God Class. A 3000-line module is a complete >> disaster. >> >> Accepted best practice is that a file too big to view on your screen is >> too long. Optimum file size is probably under 30 lines. >> > Really? I've heard that said about *function* size, but not about > *module* size. >
Really. *File* size. One should be able to view, and make sense of, an entire file. On one screen. Functions should be even smaller, IMO no more than five lines. Ideally one. Quoting from my bible for software development, Clean Code - http://amzn.to/1VWmzEV *The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that. No, we're not going to repeat exactly the same text from the Functions chapter. But as with functions, smaller is the primary rule when it comes to designing classes. As with functions, our immediate question is always "How small?"* When you work on code, work on a single piece of functionality at a time. The open file is your workbench. It should mesh well with your working memory. Admittedly this creates another type of complexity: the complexity of many files. That should be tackled through appropriate naming and structuring of files and packages: itself a (very) difficult challenge, perhaps the most difficult challenge in software development. But not the same challenge as writing clear, concise, functioning code. I just checked the Java 1.6 library source release. > 7195 *.java files. > > summary(d) > min = 9, 1st quartile = 55, median = 112, mean = 288.2, > 3rd quartile = 286, max = 9604. > "We've always done it this way" rarely means the same thing as "this is the best way to do it". And in my experience Java is *never* the right place to start when looking for examples of well-written code. By and large, the people who wrote these four different > systems were experienced and capable programmers > following practices that were adequate for developing > systems that would be used by huge numbers of other > programmers a long period. > > If large modules were *necessarily* a disaster, these systems > would not be so successful. > Large files aren't *necessarily* a disaster. If there are people out there who are capable enough, macho enough, to wrestle a 10,000 line file into something that works, I applaud them. That doesn't make working with perilously large files any easier. > I don't think I've ever seen a *non-trivial* class that would fit on a > screen > I really hate that phrase "non-trivial". It came up a lot recently in relation to the NPM left-pad fiasco, along with statements like "have we all forgotten how to program?" Small does not mean trivial. Small, single responsibility classes are perhaps the most useful and the most reusable. Programmers should not be forced to reinvent the wheel all of the time, re-writing left-pad on a monthly basis, just to prove that they are Real Programmers. Rather than "trivial" I would say "building block". Rather than "non-trivial" I would say "*composed of* building blocks (composed of building blocks (composed of building blocks (...))). Even then, I struggle to conceive of a case where a 1,000 line file could >> be broken down into 7 clear, comprehensible concepts. >> > You seem to be talking about a major rewrite, which I'm not. > I'm talking about *Single Responsibility Principle*. https://en.wikipedia.org/wiki/Single_responsibility_principle If you are modifying a file, that's because its responsibility has changed. To understand the impact of your changes to that file, you need to have clear in your mind *everything that the file does*. If it's a 10 line file, that's relatively easy. If it's a 1,000 line file, good luck! Dan Sumption -- You received this message because you are subscribed to the Google Groups "PPIG Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to ppig-discuss+unsubscr...@googlegroups.com. To post to this group, send an email to ppig-discuss@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
