> To me, a 1000-line module is a God Class. A 3000-line module is a complete
>> 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 -
*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
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
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
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*.
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,
You received this message because you are subscribed to the Google Groups "PPIG
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.