I've never seen a language's style guide recommend avoiding comments before

Avoiding comments that do what your code should be doing is common practice, and I think that&#x27;s what this style guide is recommending.<p>Comments are useful to describe __why__ you&#x27;re doing something, often when you are not able to change the unexpected behaviour. Whenever I build an API library, my code is littered with comments like &quot;Acme Corp API requires this happens before that&quot; with a link to that bit of the API documentation.<p>Here&#x27;s a C++ example about &quot;documenting surpises&quot; (taken from Steve McConnell&#x27;s Code Complete:<p><pre><code> for ( element = 0; element &lt; elementCount; element++ ) { &#x2F;&#x2F; Use right shift to divide by two. Substituting the &#x2F;&#x2F; right-shift operation cuts the loop time by 75%. elementList[ element ] = elementList[ element ] &gt;&gt; 1; } </code></pre> And a Java example:<p><pre><code> &#x2F;* The following code is necessary to work around an error in WriteData() that appears only when the third parameter equals 500. &#x27;500&#x27; has been replaced with a named constant for clarity. *&#x2F; if ( blockSize == WRITEDATA_BROKEN_SIZE ) { blockSize = WRITEDATA_WORKAROUND_SIZE; } WriteData ( file, data, blockSize ); </code></pre> He also gives a whole list of situations in which comments are a bad idea, and it&#x27;s similar to the OP.

Of course everyone thinks they always write good clean code and therefore don&#x27;t need comments to elaborate on what the heck is going on.<p>Unfortunately, having been doing this trade for 30+ years, I&#x27;ve found most people write crappy code in a hurry to try to hit some deadline based on incomplete requirements and confusing business rules. A few precious comments stuck in there can help the next guy, months or years later, figure out what the heck your original intent was or why a block of code exists at all.<p>As I get older, I find it helps me remember what I was doing.<p>One of my software developer friends was fond of saying: &quot;the worst code I ever saw was my own!&quot;<p>YES if your code is clean and elegant and well named and clear you don&#x27;t need to explain anything in common language.<p>YES you should strive for such.<p>However, the REALITY is your code sucks and no one is going to want to have to figure out what the heck you were doing. A few comments would really help.<p>The next reality is that the typical developer may be literate in a dozen or more languages and the language du jour that you coded so elegantly in has fallen out of favor and no one remembers those dusty corners you so beautifully exploited to make something work.<p>Comments would help even more if you learn to use some basic grammar and spelling when you create your comments. (It doesn&#x27;t have to be literature, but try to make your comments as readable as you think your code is - please!) Nothing will turn another developer off to trying to decipher your code than a few comments that make you look like a moron.<p>Style guides that eschew comments, IMO, are counterproductive. They feed on the developer&#x27;s ego and disregard reality.<p>Comments cost essentially nothing to add to your code and can save it from an early death and complete refactoring by the next guy who comes along.

Robert C. Martin&#x27;s Clean Code book has a great section on comments:<p>- The proper use of comments is to compensate for our failure to express ourself in code. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration. So when you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code.<p>- The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can’t realistically maintain them.<p>- Comments Do Not Make Up for Bad Code! One of the more common motivations for writing comments is bad code. We write a module and we know it is confusing and disorganized. We know it’s a mess. So we say to ourselves, “Ooh, I’d better comment that!” No! You’d better clean it! Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments. Rather than spend your time writing the comments that explain the mess you’ve made, spend it cleaning that mess.<p>``` &#x2F;&#x2F; Bad:<p><pre><code> &#x2F;&#x2F; Check to see if the employee is eligible for full benefits if ((employee.flags &amp; HOURLY_FLAG) &amp;&amp; (employee.age &gt; 65)) &#x2F;&#x2F; Good: if (employee.isEligibleForFullBenefits())</code></pre> ```

I see rubbish like this in PHP (and Java) code all the time:<p><pre><code> &#x2F;** * Frobnicates a foobar * * @param Foobar $foobar The foobar to be frobnicated * @param int $intensity The intensity with which the foobar will * be frobnicated (defaults to 4) * @return mixed The result of frobnicating a foobar *&#x2F; function foobar_frobnicate(Foobar $foobar, $intensity=5) { &#x2F;&#x2F; frobnicates the foobar return $foobar-&gt;frobnicate($intensity); } </code></pre> It&#x27;s utterly ridiculous.<p>Pretty sure I&#x27;ve been guilty of this in the past, too. As I recall, the documentor tools make a lot of noise if you don&#x27;t supply wasteful and irrelevant values for every single little thing even if it&#x27;s blindingly obvious from the symbol, context or idiom what it means and what it does.

Hmm. This is just one guy&#x27;s style guide on the public wiki.<p><a href="http://www.haskell.org/haskellwiki/index.php?title=Commenting&amp;action=history" rel="nofollow">http:&#x2F;&#x2F;www.haskell.org&#x2F;haskellwiki&#x2F;index.php?title=Commentin...</a><p>It isn&#x27;t official in any sense.

I&#x27;ve always treated comments as code smells. Not necessarily something bad, but something that at least suggests the possibility of suboptimal code.<p>One of the best cases for comments IMO is documenting an unexpected behaviour on the part of a third-party API. But even then, correct exception &#x2F; error-handling code can obviate the need for comments in many cases.<p>If I&#x27;m reading code (from an experienced programmer) and I see a comment, I immediately pay attention, because Here Be Dragons.

Comments say <i>what</i> your code does, your code says <i>how</i> you do it. The swap example is trivial, but for most functions it is good to add an API comment, because how you use the function shouldn&#x27;t depend on how it&#x27;s implemented, but what it should do, described in the comment. That way you can change your implementation as long as you don&#x27;t change the contract. In other words, changing how your code does something shouldn&#x27;t therefore change what it does. And this last part is specified in the comment.

Here&#x27;s a small function from a real world module used in a Haskell web backend. It decides whether a &quot;work unit&quot; is appropriate to pick from a queue. The first iteration was a pretty complex piece of code. When I refactor, I often think &quot;this is unclear and should be commented,&quot; but I&#x27;ve learned instead to think &quot;this is unclear and should be factored out and given a significant name.&quot; So I ended up with this:<p><pre><code> shouldPickWorkUnit :: (ImportId, WorkUnit) -&gt; STM Bool shouldPickWorkUnit (k, u) = case hostNameFor url of Nothing -&gt; return True -- Invalid URLs are fast to process. Just hostName -&gt; takeWorkThat&#x27;sAlreadyDone &lt;*&gt; (don&#x27;tTakeSomeoneElse&#x27;sWork &lt;*&gt; don&#x27;tExceedTheRateLimitFor hostName) </code></pre> This way, the domain logic is legible from the actual code, which strikes me as almost always better than having tricky code with comments. Trying for this also encourages &quot;domain-driven abstraction,&quot; and this is one of Haskell&#x27;s greatest strengths.<p>In fact, the remaining comment can be factored away too:<p><pre><code> shouldPickWorkUnit :: (ImportId, WorkUnit) -&gt; STM Bool shouldPickWorkUnit (k, u) = takeWorkWithInvalidUrl &lt;*&gt; (takeWorkThat&#x27;sAlreadyDone &lt;*&gt; (don&#x27;tTakeSomeoneElse&#x27;sWork &lt;*&gt; don&#x27;tExceedTheRateLimitFor hostName)) </code></pre> Advice like &quot;avoid comments&quot; needs to be taken as a calling for actually spending time and effort to write obvious code, and for using appropriate abstractions!

It&#x27;s doesn&#x27;t recommend avoiding comments - it encourages to write understandable code and avoid meaningless comments. It is a basic rule of the clean code.

The thing with comments is: You should add them for people that don&#x27;t want to read your code line by line.<p>I don&#x27;t want to run my internal compiler in my head when i&#x27;m reading your code, so you better make sure there&#x27;s at least a docblock above every function that describes in 2 sentences what it does so I can get a global overview of what the heck this file is doing.<p>People that suggest that &#x27;the code is the documentation&#x27; are always forgetting that reading code is way more taxing on the brain than reading english.

I&#x27;ve found there are several topics that even qualified, experienced, reasonable developers will always disagree on. dynamic vs static typing, YNGNI vs future proofing, IDE vs no IDE etc. Usually, a given developers opinion on these topics is informed by their specific experience and what has bitten them in the past.<p>Code comments definitely fall into this category. I&#x27;ve worked with developers who I greatly respect who are obsessive about code comments. I&#x27;ve even been told that the comments are more important than the code and in that specific context it made sense.<p>But my own experience and biases make me think code comments are a problem. I like to refer to them as future lies. There is virtually no back pressure on comments to keep them in sync with the code. There is no automated way to verify them and refactoring tools on comments are rudimentary at best. To put it simply, I no longer trust comments and will usually ignore them in order to verify the code itself. I can&#x27;t count the number of times I&#x27;ve found comments that directly contradicted the code it was commenting. It isn&#x27;t even uncommon to find comments that are incorrect when they are written!<p>As to the folks recommending comments that document the &quot;why&quot; of a piece of code, I&#x27;d counter that if you have a &quot;why&quot; you have a specification. If you have a specification it should be verified in a systematic way. So performance improvements, or specific client requirements should be encoded in tests so that they don&#x27;t regress. Comments do not provide that safety.<p>That&#x27;s not to say I never comment my code. Just that it always feels like a failure when I do. It is usually because it is cheaper to comment than to provide cleaner code or better verified specifications.

It seems like no one here shares my opinion on this: I really like comments, even if they just restate, in English, what the code does. I don&#x27;t think that&#x27;s pointless. There is big value in it. I can scan and mentally process English sentences much faster than code. With a heavily commented file you can just skim through the comments until you locate the part you need to work on (then slow down and read the code around it and edit it).<p>Look at the Backbone.js annotated source [1] (the stuff on the left is just the comments pulled out from the original source JS). The comments make it much, much quicker to grasp what&#x27;s going on, even though many of them just state exactly what the corresponding code does, which according to the Haskell docs&#x27; advice is pointless and to be avoided.<p>[1] <a href="http://backbonejs.org/docs/backbone.html" rel="nofollow">http:&#x2F;&#x2F;backbonejs.org&#x2F;docs&#x2F;backbone.html</a>

&gt; I repeat: Try hard - very hard - preferably repeatedly - to remove unexpected behaviour from your program. Comments can never fix unexpected behaviour.<p>This is golden!

I&#x27;ve seen this many times:<p><pre><code> ...thus they (comments) tend to diverge from actual implementation. </code></pre> It happens, you update&#x2F;refactor code, and forget to update the comments. Thus the comments are outdated or worse not applicable anymore. Common mistake by less-detailed oriented developers. Begs the question, in this case is is better to have confusing&#x2F;incorrect comments, or no comments at all?

I&#x27;m a big believer in function level comments in code, in a sort of doxygen-ish style (I write mostly C).<p>It allows you to document the intended inputs and outputs of the function and state its purpose. This increases maintainability and reusability.<p>Functions themselves should be short and written as a sequence of logical steps.<p>I&#x27;m also a big fan of doing things right rather than just hacking until it works, which seems to put me in a minority.

Comments are lousy for describing <i>what</i> you are doing, but there are no alternative to comments for describing <i>why</i> something is done.

Similar thoughts were seen in the SICP book.<p>&quot;In this book we don&#x27;t use many comments; we try to make our programs self-documenting by using descriptive names.&quot;<p><a href="http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html#footnote_Temp_197" rel="nofollow">http:&#x2F;&#x2F;mitpress.mit.edu&#x2F;sicp&#x2F;full-text&#x2F;book&#x2F;book-Z-H-15.html...</a>

Note that this isn&#x27;t the &quot;official&quot; Haskell style guide. We don&#x27;t have one (although we probably shouldn&#x27;t). This is one of the competing guides out there.

I&#x27;d say the language design and language ecosystem has a LOT to do with it as well. Here are a few lines of Java that I just had to write about 10 minutes ago.<p><pre><code> PendingResult&lt;MessageApi.SendMessageResult&gt; pending = Wearable.MessageApi.sendMessage(mGoogleApiClient, mWearableNode.getId(), path, data); pending.setResultCallback(new ResultCallback&lt;MessageApi.SendMessageResult&gt;() { @Override public void onResult(MessageApi.SendMessageResult result) { .... } } </code></pre> Okay, now suppose this were a Python-based API instead? Perhaps it could be something like this, after some relevant initialisation:<p><pre><code> wearable.sendmessage(mywearable, path, data) @wearable.onresult def onresult(result): ... </code></pre> Tell me which one is more in need of commenting.

I totally agree with this. I like to put a bigger comment block at the top of my source files explaining the overall concepts and data structures used and then put few actual comments in the code. Instead I think about my variables and function names and make them talk for them-self. Commenting each and every element of your code will just make people (possibly yourself) curse at you when debugging your code and realizing that the comment was rendered obsolete 15 iterations prior and the code does something entirely different.

Leo Brodie says in &quot;Thinking Forth&quot; in the style section: &quot;The most-accurate, least-expensive documentation is self-documenting code&quot;. I am sure there are other prior examples.

I agree. Comments sometimes make it difficult to go through the source code. That&#x27;s why I always loved Java naming convention that suggests variables and method names to be self-explanatory.

I currently write docblocks for everything I code.<p>It&#x27;s crazy how much time I spend on them and sometimes they are confusing because the specs change and I keep forgetting to add&#x2F;remove&#x2F;update something in a docblock when I rewrite some part of the code it documents (I&#x27;d say between 10-20% of my commits are docblock updates).<p>I believe brief or even no documentation may be the best approach until you are on the verge of releasing a stable version.<p>While you are on developing and testing mode, it seems a better idea to forget about comments and focus on modularity.<p>After all, Why would I need comments if all the rest of my team sees is an interface satisfying a previously established and well defined contract? That&#x27;s why docblocks should be only documenting public interfaces, some kind of dump taken from the part(s) of the contract they implement.<p>I&#x27;d consider instead other top priorites on those phases:<p>- Keeping an homogeneous codebase in regard of design and coding guidelines and conventions.<p>- Re-factoring before it becomes a problem<p>- Writing neat unit and integration tests<p>And, the most important:<p>- Keeping a channel open with the client, constantly feeding guided demos and prototypes showing your progress to make sure you are on the right track and you didn&#x27;t get it backwards, updating specs and being realistic about what can be done and what not in which time frames with the provided resources.

&gt; I&#x27;ve never seen a language&#x27;s style guide recommend avoiding comments before<p>An official style guide? Maybe. But it is one of common philosophies. See for example:<p>&quot;If you need to comment something to make it understandable it should probably be rewritten.&quot;<p><a href="http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code" rel="nofollow">http:&#x2F;&#x2F;kotaku.com&#x2F;5975610&#x2F;the-exceptional-beauty-of-doom-3s-...</a>

There&#x27;s similar advice in the Ruby Style Guide - <a href="https://github.com/bbatsov/ruby-style-guide#no-comments" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bbatsov&#x2F;ruby-style-guide#no-comments</a><p>Comments often go out-of-sync with the code, so I think it makes a lot of sense to prefer writing comprehensible code instead of trying to explain with comments something totally incomprehensible.

The stablished policy is: &quot;don&#x27;t use comments to replace proper names and abstractions&quot;.<p>I wrote more about this here (it&#x27;s Lua code, but it applies to any language):<p><a href="http://kiki.to/blog/2012/03/16/small-functions-are-good-for-the-universe/" rel="nofollow">http:&#x2F;&#x2F;kiki.to&#x2F;blog&#x2F;2012&#x2F;03&#x2F;16&#x2F;small-functions-are-good-for-...</a>

This is not convincing to me because the examples are trivial:<p><pre><code> -- swap the elements of a pair swap :: (a,b) -&gt; (b,a)</code></pre> Yes this is redundant.<p><pre><code> let b=a+1 -- add one to &#x27;a&#x27; </code></pre> Yes this is also redundant<p>Does it mean that every piece of code can be expressed as clearly as in a one-line comment in natural language? I don&#x27;t think so.

The article correctly advices against commenting the obvious. I think it is often practice by novice programmers to assure themselves about what the language expression actually does.<p>What the article omits is the suggestion of commenting the right way, i.e. adding reasoning or the description of the high level logic behind the code.

Code may explain <i>what</i> your code is doing, not necessarily <i>why</i> it is doing what it does in the way it does.<p>Comments may be a code smell when it is necessary to explain what your code is doing.<p>Anywhere where you have some freedom to solve a problem one way or the other it may clarify why the implemented approach was chosen.

Comment only magical code, but don&#x27;t write magical code.

There are times when you absolutely want to comment something like an &quot;Add&quot; or &quot;Swap&quot; function.<p>eg.<p>&#x2F;&#x2F; The reason we use a custom swap function instead of<p>&#x2F;&#x2F; the one that is shipped with the framework is because<p>&#x2F;&#x2F; of an edge-case that occurs quite frequently in our<p>&#x2F;&#x2F; scenario<p>&#x2F;&#x2F; Refer to Change Request 345.<p>void Swap (Foo a, Foo b) ....

Comments I liked to write were when I found successive optimizations (lots of symmetries in the algorithm) leading to very short code. Almost too factored to be understood easily so I added a comment wall above telling the steps I went through before hitting the final code below.

It is easy to spot (most of) the experienced coders from the newbie coders. Any programmer who has written his salt worth of code knows that comments can save your ass. Come back to some code ten years later and you can sit there staring at a bit of code no bigger than your thumb wondering what the hell it does and often it doesn&#x27;t become clear until you shove some test samples down its interface and see the result. Whereas a simple comment is all it would have taken to clear it up from the start. People who argue that comments can get out of whack with code, well, of course they can, but that&#x27;s no excuse. That&#x27;s just a failure on the programmers part to always update comments when the code changes.

Personally I have no problems with comments in code for complex functions etc. But pointless comments like this below drives me insane.<p>&#x2F;&#x2F; get the user $user = $this-&gt;getUser();<p>Times that by the thousands of lines in a project and you have one big headache!

It&#x27;s often a good idea to comment &quot;why&quot; the code exist, if it is non-obvious (e.g. it&#x27;s obvious to sanitize input parameters). The comment must be short and possibly point to a ticket wrote somewhere else.<p>It may be a good idea to comment &quot;what&quot; the code does, if it isn&#x27;t clear (the code itself is &quot;how&quot; it is done, but &quot;what&quot; does it do may be hard to read, e.g. sometimes you use a clever hack for performance reasons).<p>As always, handle with care :-)

I was always told that if someone couldn&#x27;t tell what your code was doing by glancing at it, you&#x27;d done it wrong and should re-write it.<p>I know that&#x27;s absurd in practice, we don&#x27;t always have the time but I&#x27;ve always used comments as a last resort.<p>If I need to comment code to make it understandable at a glance, so be it but I&#x27;d rather avoid them all together and rewrite until it&#x27;s clear enough without them.

Write comments that explain why a certain line is there.<p>Let&#x27;s say you are parsing a standard tab delimited file. You find that the tab delimited file has some non-standard features, so you have to write some extra lines of code to handle it. For people who thinks the code just parses a standard tab delimited file, these lines will be confusing, so you comment these lines and say why you included them.

This style guide is NOT against comments. It is just stating the obvious best practices which have always been around for all languages ...

This submission needs to have a different title. It&#x27;s not very clear whether the submitter is being genuinely surprised or sarcastic.

This style guide DOES recommend avoiding unnecessary comments and is an easy one to understand and remember. Good start for all novice coders. <a href="https://google-styleguide.googlecode.com/svn/trunk/shell.xml" rel="nofollow">https:&#x2F;&#x2F;google-styleguide.googlecode.com&#x2F;svn&#x2F;trunk&#x2F;shell.xml</a>

Linkbait title. Rolls eyes yet again.

Martin Fowler&#x27;s <i>Refactoring</i> says that, possibly paraphrasing here, most comments are bugs.<p>I do favor putting a short comment on some methods&#x2F;functions&#x2F;procedures.

Articles about writing code without commenting sound like articles about driving your car without using the brakes: theoretically possible, but impractical.

Its quite common in coding communities and style guides.

Comments aren&#x27;t necessary at all. If the code was difficult to write, it should be difficult to read. :-P

Read the linked page. This one doesn&#x27;t either. It says to prefer fixing bugs over documenting them.

To rephrase - code makes comments understandable?

The article is spot on. Comment as last resort.

Good code should be self documenting.

You want a good rule: Write More Comments! Comments are documentation and few programs are ever documented enough.

how about a language that has no support for comments!?

A partial list of problems<p>Assume someone who can&#x27;t write clear code can write clear comments. Also search and replace clear with &quot;readable&quot; &quot;literate&quot; &quot;concise&quot; and last but not least, &quot;correct&quot;<p>Assume a programmer has full authority over all 3rd party, supplier and customer APIs, interdepartmental processes, and all business logic, management selected fad technologies, such that its logically impossible to be unable to always factor out weird confusing stuff resulting in clear code &#x2F; clear comments. My program is the world and none have dominion over any of the rest of it and any other conception of reality is wrong. (And edited to add I&#x27;ve gotten involved in some weird &quot;EE&quot; stuff and like it or not, the world itself is plain old weird and illogical sometimes and if you don&#x27;t like that, a computer programmer can&#x27;t fix it, only a physicist, or maybe a diety. This isn&#x27;t a big problem in the world of CRUD apps but it does happen)<p>Assume comments only exist as a inspirational descriptional prose tool. Sometimes I use them as placeholders for something I know belongs there but either I or the business are not ready. Sometimes I use them as a cheatsheet because I&#x27;m personally really uncomfortable. Sometimes I use them as an outline more like names on a map to orient myself than a travelogue.<p>Assume all programmers fit the management ideal of identical replacable cogs. &quot;How could someone work here without knowing by heart how to convert dBmW into volts or the difference between S21 and S12 microwave scattering parameters, so I have no need to comment this, but I&#x27;ve never actually used this corner of matrix math while employed before so I&#x27;ll make one of those laughable comments that is a simple linear translation just to help me keep my head on straight.<p>Assume comments go thru the same code review process as code. If a comment in file A tangentially relates to function Q in file B, and you modify function Q, your code review process will probably examine file B and the comments in it, but how do you ensure file A gets modified? This is especially bad with those &quot;because&quot; style comments. (edited to add, at least date your comments?)<p>Assume no metrics exist WRT comments to be gamed. Your continued employment and possible promotion exist because of a content free meaningless metric number, perhaps lines of comments. Ask a professional to generate a number, you&#x27;ll get a nice number, but unprofessional work. Ask a professional to do professional work, and you get professional results and who cares what the number is. That requires a high caliber of management, usually unavailable. Even worse a low caliber of management, the kind most likely to demand adherence to meaningless metrics, is also exactly the type least likely to successfully evaluate the professionalism of the code so they don&#x27;t end up with good code. So you get meaningless metrics resulting in meaningless comments right next to bad code, if you enforce metrics.<p>Assume there exists a silver bullet for comments, just like this months silver bullet fad for code also fixes all problems.<p>(edited to add) Assume there&#x27;s one human language. I worked at a place where outsourcing and H1B took complete control over corporate IT such that code comments and even some internal documents were no longer written in English. This makes comments rather hard to follow when engineering tries to cooperate with IT. So... I&#x27;d love to follow your detailed internal process for dynamic DNS for my spectrum analyzer, but you guys don&#x27;t use English and we don&#x27;t use your India language, so...

I disagree. You don&#x27;t need to comment simple and <i>universal</i> concepts like this:<p><pre><code> swap :: (a, b) -&gt; (b, a) swap (x, y) = (y, x) </code></pre> or even this:<p><pre><code> map :: (a -&gt; b) -&gt; [a] -&gt; [b] map f [] = [] map f (x:xs) = (f x):(map f xs) </code></pre> Those functions actually <i>are</i> self-documenting. Trying to explain them further is just going to clutter the page.<p>On the other hand, at 10,000 lines of code, a lot of that being parochial business logic, I&#x27;m going to want high-level documentation of <i>why</i> all this code exists. My emotional impulse is going to be to throw out all this shit code (in the business world, all code is shit) so please <i>tell me</i> why that is a bad idea. (I know it is, and I&#x27;m not going to do it, but please tell me <i>why</i> I&#x27;m not going to do it.) I&#x27;m going to want an entry point. I can&#x27;t count the number of days of life I&#x27;ve lost just looking for entry-points in gigantic enterprise codeballs. Like, what actually runs?<p>Actually, 10,000-line single-programs should be rare-- Big Software is almost always a mistake, see here: <a href="http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/--" rel="nofollow">http:&#x2F;&#x2F;michaelochurch.wordpress.com&#x2F;2012&#x2F;04&#x2F;13&#x2F;java-shop-pol...</a> but that&#x27;s another rant.