On object-oriented programming: "That which obscures my code is bad."

Whenever I hear strong opinions about coding styles I politely nod, agree and then launch into a series of questions designed to understand the background of whoever is articulating the opinion.<p>Yes, coding style is shaped by personal preferences (where do YOU put your curly braces?), cultural affiliation (Microsofties and Hungarian notation) and a variety of other minor factors. However these are secondary to the main issue of how programmers build an underlying structure of the code. Structure is somewhat of an elusive concept, but use of object oriented programming (proper use) certainly leads to structural changes in the code. Along the same lines, use of recursion leads to a different structure than use of procedural style and so on. In short, structure for me is the underlying mathematical solution to the problem addressed by the code, regardless of the specific programming language.<p>So going back to the issue of the coding style, I find that the background of the programmer is so important because it shapes their thinking about typical code structures. Someone with a background of writing payroll or other corporate financial systems (like many Thoughtworkers) falls naturally into a habit of thinking about code as a close approximation, if not a one-to-one representation of real worlds objects. Others with a systems background, who excel at using Nth order pointers to save 5Kb of RAM in a device driver care less about the real worlds objects than about differences in x86 parallel processing instruction semantics.<p>However, if you put a systems dev guy and a corporate dev guy in a room together and make them talk to each other about programming they'll happily argue for days about how the corporate dev guy is a loser for not saving memory through pointer arithmetic and the systems guy is an idiot for not "getting it" about object oriented programming.<p>So, to make the long story short, conversations about how &#60;insert programming paradigm here&#62; rocks/sucks are pretty much useless unless one first understands the target audience for the paradigm.

Interestingly, research results on this come out in favor of longer functions. I read this a long time ago (in the book Code Complete) and remembered it because it went against my assumptions. Can't get at it in Google Books but a summary appears here: <a href="http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/routines.html" rel="nofollow">http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/l...</a><p>Examples:<p><pre><code> Routine size is inversely correlated with errors, up to 200 lines of code Larger routines (65 lines of code or more) are cheaper to develop per line of code </code></pre> There are all sorts of objections one can make to this. Perhaps it indicates as much about the weakness of software research as anything. But I still find it interesting enough to temper my opinions.

I don't think you've identified badness with OO programming styles; I think you've identified badness in the community of Thoughtworks developers.

I quite liked the guidelines in that blog post. I don't do <i>exactly</i> that myself, but as rules of thumb they aint bad! But like a few folk have pointed out, it's about personal style, background and context.<p>One thing I like to do is use naming of Packages &#38; Namespaces to tell a story about the system. So, you can look at the packages and understand what the important aspects to the system are.<p>Example:<p>- Spidering - Feeds - Pages - Control<p>- Indexing - Strategy - Scheduling - Lucene<p>Also, when you return to a code base years later, you can scan the namespace story to get a reminder of the key areas of the system.

This is all a matter of personal taste.<p>With small methods you indeed make code hard to read and harder to debug. Plus you generate method calling overhead (yes I know, a smart compiler will inline - but if thats true, you can inline yourself). Combine atomic methods with a wealth of design pattern, and your code may become absolutely unmaintainable (all in the name of pure object orientation and better maintainablility).<p>If - else chains cannot be avoided with small methods (one for if and one for else). You just move the if else to the point, where the decision for the one or the other methods has to be made. A smart replacement for if else chains is switch.<p>But as I said, please no flamewar. I think the best you can do is to leave every programmer with his own style. That will make him most productive. All these stupid rules come from non programming managers, who want one style throughout their whole codebase, because they believe this makes every programmer easily replacable. This is no developers interest (and its not true anyway).<p>Pure oo style leads to some very dangerous constructs. In my experience, the true oo scholars often produce slow code, thats a memory sink (ever created a new object in a loop?).<p>Like with patterns, it needs a lot of experience to know, when to use them and when to avoid them. These truly simple rules, are in my opinion made for beginners (and I tend to say also: by beginners).<p>What matters most, is a clear style, comments, well chosen variable names. Everything that makes your code easier to understand - and that mainly for you, the author, because if someone has to maintain your code, he very likely will rewrite it. And that can be smart, because most of the time its the faster way.

I am reminded of the constant fight to explain the difference between "if" and "iff."<p>We observe that really great OO code has small methods that do one thing well. IF great-oo THEN small-methods.<p>So is the answer to go out and refactor code so that each method only does one thing? This makes a different assumption: IF_AND_ONLY_IF great-oo THEN small-methods.

I'm sure that object decomposition does not per se, automatically, lead to code obfuscation. If the design is decent, it should be, if not obvious, then at least possible without too much ado to determine where in the file tree methods shaved off larger objects should be placed so that somebody who knows how the file names are chosen, but doesn't know the code itself, can find them by looking at a list or a diagram.<p>I find a "limit" at indentation depth 1 a bit overly harsh, but I at least casually consider it whenever I reach depth 2, and at depth 3, I <i>really</i> try bailing out, foregoing "else", too. And sometimes I even do it at depth 1, and get a nice fuzzy warm feeling from that. <i>Edit: This was underplaying it too much. "Callisthenics", cleverly used, really</i> do <i>help to organise the code if you have something conceptually larger, e.g. a DSL, to capture the knowledge as it is abstracted from the data.</i><p>Then again, I prefer using function composition over inheritance whenever I can, so my whole work method is geared towards managing many small files. Systems of names, essentially. I think a lot in terms of names and naming systems.<p>Transparency, AFAICT, needs to be built into the design, via an ongoing effort for the seperation of concerns (systematic naming is crucial in that). Which has me trending towards smaller objects over the years. That's just my experience; YMMV. But I don't see how moving from, say on average, 50-LOC-objects to 100-LOC-objects now would make my codebase in any way less "obscured".