A good program is 500 lines or less.
I'm not sure I agree. How about: "there's no such thing as a bad short program".
Programs should be Small
11–20 of 75 posts
Re: Programs should be Small
#12A good program is 500 lines or less.
I type at least 60,000 characters before inserting a line break. I joke, but I've seen some php before that was at least 600 chars before line breaks, I have no idea how they wrote it like that.
Broken 'enter' key; it's the only way I can imagine while clinging to sanity.
Re: Programs should be Small
#13There is value in reading pages of legacy code. Its very common to watch new hires solve an already solved problem. Too many people are allergic to reading code it seems.
Solving complex problems in the physical world usually results in complexity in the source code world.
It is always overwhelming to jump into a new gigantic code base. Talk to someone who's been on it a while and they won't have the same drowning outlook.
Re: Programs should be Small
#14This seems akin to the saying that "everything should be made as simple as possible, but not simpler." Well, yeah. simplifying to that point isn't exactly easy. And, worse, the act of simplifying your code to fit this description is something that is usually done after you had it working. In other words, instead of solving another customer problem, many folks spin wheels "solving" their own "problems." Even worse, often the solution is taken to that simpler place that the saying warns against.
Re: Programs should be Small
#15A good program is 500 lines or less.
I'm not sure I agree. How about: "there's no such thing as a bad short program".
Depends on the problem. Sometimes a "short program" means omitted error handling, lax input validation, not covering necessary edge cases and generally the sort of thing that leads to bugs and security holes. I prefer the word "concise"- brief but comprehensive.
Re: Programs should be Small
#16The problem is that software has a tendency to become complex. The proposed solution is to break up the software into smaller programs. There are certainly advantages to having smaller components. It allows you to rewrite components in a different language should you want to, for example. But there are disadvantages to: smaller components means dealing with failure at a much finer granularity. In my opinion, the reas…
Can you please elaborate on "reason about parts of a program in terms of what they mean rather than what they do"?
Re: Programs should be Small
#17A good program is 500 lines or less.
Wow, it seems rather arbitrary. Can you elaborate?
Yes, it's arbitrary and there are of course exceptions and perhaps domains where it may not apply at all. It's just a recurring observation that I've made (mostly but not only) in dynamic languages.
Pretty much all good code that I've read or written was compartmentalized into units of roughly 500 LOC. A big program may be composed of many such units, but it was almost always a bad sign when a divisible part would exceed the "magic" number.
What comprises a divisible part of course also varies by language; at the least it'd be the LOC-per-file, but usually it'd be a self-contained and separately tested module.
In a moment someone will probably come up with a great piece of software where this doesn't hold true, I'd actually be curious to see it.
Re: Programs should be Small
#18Certainly perpetuating the illusion that all Java code is "enterprisey" and "monolithic" will get tiresome at some point, right? I sure am tired of reading such views.
Re: Programs should be Small
#19The problem is that software has a tendency to become complex. The proposed solution is to break up the software into smaller programs. There are certainly advantages to having smaller components. It allows you to rewrite components in a different language should you want to, for example. But there are disadvantages to: smaller components means dealing with failure at a much finer granularity. In my opinion, the reas…
> But there are disadvantages to: smaller components means dealing with failure at a much finer granularity.
I am really curious why you see this as a disadvantage. At my current job, I've had the experience of moving from a relatively small backend system that was broken up into discrete message-passing parts to a larger frontend system that was mostly one monolithic project. The former was by far much easier to debug, despite it being much older, less sophisticated, and having less logging, simply because it was easier to isolate and reproduce problems. The queues also made it very easy for us to bring down, diagnose, or scale individual components as they ran in production.
I couldn't see this as anything but an advantage, and one that's well worth the added complexity once you pass a size threshold.
And sure you can just go cowboy and say "I'll make it simple anyway!," but firstly, interface-enforced simplicity is not the only reason you would go with queues and RPC (other reasons have been mentioned in the article or by myself), and secondly, it is much more difficult than you think to enforce such abstract common disciplines on a large project.
Re: Programs should be Small
#20I love all these articles which are wholly ignorant of how complex software is in reality and how such advice isn't necessarily good.
Sometimes decomposition results in problems at the other end of the scale such as communication performance, data duplication, extremely nested abstractions, messaging complexity, contract and API versioning hell etc.
Getting the sweet spot between monolithic coupled blobs and fragmented latent deathtraps is an art which can't be puked out in a blog post. It takes literally years of experience and some guesswork and testing and thinking.
Ultimately, lots of small programs are just as painful as a single large one if they have to talk to each other or do IO.