Live data from Hacker News

Refactoring wars and how to avoid them: what is "simplicity" in programming?

reprog.wordpress.com

31–35 of 35 posts

Re: Refactoring wars and how to avoid them: what is "simplicity" in programming?

#31
post #9

Earlier quoted context omitted.

For Java I agree, more and shorter methods are better. But then I see Haskell programs with zillions of one-line functions and higher math to do trivial things, and then I can understand where he's coming from.

I'd suggest that the important thing is not how many lines a function has, but whether it represents a single, cohesive idea. Haskell functions aren't shorter because someone decided one day that they should be, they are shorter because Haskell is relatively expressive in some areas. Concepts in suitable areas that would take several lines to represent in another language might take only a line or two in Haskell. On…

"I'd suggest that the important thing is not how many lines a function has, but whether it represents a single, cohesive idea."

I think you have it exactly right, and I wish I'd made that point, as clearly as this, in the original article (or indeed in the followup, which I stupidly did before reading the HN comments about the original.)

A function/method is like a paragraph in prose writing. Any good style book will tell you that there is no "right length" for paragraphs (although bad teachers might teach rules like "no less than three lines, no more than ten". A paragraph should be exactly long enough to convey one clear point, whether that takes one line, ten, or twenty. The same for functions.

By the way, I'd like to say that a LOT of the comments on this thread are really insightful (i.e. the include insights that are new to me, but which immediately make sense once I see them written down). It's pretty humbling to see this community so quickly come to so many valuable conclusions when my poor, bumbling article took so long to get to where it did. Thanks to all who have contributes -- I hope you'll stick around on The Reinvigorated Programmer and contribute to the discussions on there, too.

Re: Refactoring wars and how to avoid them: what is "simplicity" in programming?

#32
post #30

We are far too willing to dismiss things as mere "personal preference" in this industry. There may be competing theories all supported by some empirical evidence and sound logic, but some claims are directly contradicted by hard data. Those claims are not just a personal preference for the best way to do things. They are measurably, objectively wrong, and failing to say so is just being nice because we don't want to…

Code that falls in line with your expectations and caters to your mental toolkit is easy to understand. It also helps when code works well with your existing programming environment. I work with Java programmers and C++ programmers, and they both have ways of jumping quickly to class and method definitions, but the C++ programmers' way -- incremental search -- only works within a single file. The Java programmers bar…

I'm certainly not advocating complete uniformity in how everyone does everything, but I think we have to be careful about judging programming style based on artificial limitations. Static code navigation, on the level of your examples, is essentially a solved problem. If the developers you work with are using tools that can't do it, or aren't using the tools they have to best effect, then they have a basic problem that has little to do with coding style.

Re: Refactoring wars and how to avoid them: what is "simplicity" in programming?

#33
post #13

this entire blog post reduces thusly: "hiding complexity with abstraction and encapsulation is not simplification, but further increases cognitive load as the abstractions must be undone to fully comprehend the function of the code." It is an interesting point, sure. I think the example as given makes his point fairly well. The question becomes: when does hiding complexity improve your ability to reason about the cod…

Is the goal to hide complexity? Any non-trivial program is going to be complex no matter how you refactor it.

For me the goal is to divide the complexity at natural boundaries so I can just focus on a portion of it. Sometimes I care about the abstract contents of an object I'm transmitting. Sometimes I care about how objects in general are serialized into a stream. Sometimes I care about how a stream is spread across TCP packets. But I hardly ever care about all these layers simultaneously, and it'd be harder to make any changes I need if I had to understand and correctly maintain the invariants of all of them.

Re: Refactoring wars and how to avoid them: what is "simplicity" in programming?

#34
post #29

Earlier quoted context omitted.

> When you trust the abstraction I agree. I would also say that in cases where the abstraction doesn't make sense you have to know what's going on inside the box in order to trust it. In your example, the file system as an abstraction makes sense because once you understand that it's a tree, you are pretty much good to go. I remember working on some projects early in my career with a very senior developer who had a h…

I agree. I would also say that in cases where the abstraction doesn't make sense you have to know what's going on inside the box in order to trust it. Recently at my day job, I came across a string trim() function, which started with this comment: // removes leading and trailing whitespace. Also removes commas. The code itself also removed single trailing periods. That really hurts your trust in the code base - you n…

All I can say is fascinating.

I don't think it can be drilled into developer's heads enough, that someday, somebody else will have to deal with this code. And that person might even be them 4 years from now.

Re: Refactoring wars and how to avoid them: what is "simplicity" in programming?

#35
Well, I like two definitions.

1: From the Agile Manifesto (http://agilemanifesto.org/principles.html):

Simplicity--the art of maximizing the amount of work not done--is essential.

2: From Kent Beck on Extreme Programming:

Simplicity is the most intensely intellectual of the XP values. To make a system simple enough to gracefully solve only today's problem is hard work. Yesterday's simple solution may be fine today, or it may look simplistic or complex. When you need to change to regain simplicity, you must find a way from where you are to where you want to be.

And a related one from Antoine de Saint-Exupery:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away

Post reply on HN