This blog post is the last part of the mini series about Framework Design Principles.

Fewer lines of code is better. Given that it sill solves the problem. Less code means less debugging, less testing and fewer bugs. A framework has to make sure that the programmers using it can express concepts succinctly and still clearly. Also, the framework or library should not encourage the developer to hide essential parts of the code just for the sake of succinctness.

Succinct is good

I guess an example would be handy right now. The example I used in my talk at “Mathema Campus” earlier this year is from Paul Graham’s article Take the Arc Challenge. The challenge is:

Write a program that causes the url said (e.g. http://localhost:port/said) to produce a page with an input field and a submit button. When the submit button is pressed, that should produce a second page with a single link saying "click here." When that is clicked it should lead to a third page that says "you said: ..." where ... is whatever the user typed in the original input field. The third page must only show what the user actually typed. I.e. the value entered in the input field must not be passed in the url, or it would be possible to change the behavior of the final page by editing the url.

Imagine solving this challenge using your favourite web framework… In Apache Wicket, for example, one would have to write 2-3 Java Classes, 3 XHTML-Files and an XML file to solve the challenge. In JSXP it’s just about the same effort.

This is the solution written in ARC, the Lisp-dialect created by Paul Graham:

(defop said req
  (aform [w/link (pr "you said: " (arg _ "foo"))
           (pr "click here")]
    (input "foo") 
    (submit)))

The beautiful thing about this solution is that it is really short, but still does not hide anything essential from the reader: Everything from the original requirements can be found directly in the code.

Reasons

There are several reasons why less code is better. An important one is Working Memory Capacity (which I have explained in an earlier article from this series). Programmers have to remember large parts of the code correctly so they can modify it. They have to “Load” it into working memory - This is what gets programmers into “flow”. Succinct code means that the programmer can “load” more code more quickly.

There is also some evidence that the number of lines of code a programmer writes per hour is independent of the programming language - also the number of bugs per line of code seems to be pretty independent of the technology used (see for example this paper by Ericsson). So, less code means less bugs and more productivity.

Finding errors is easier too: There is less code where the bug can be hidden, and there are probably less tests affected.

Too succinct

Can a piece of code be too succinct? It can, if it hides things that are essential to understand what the code does. Consider this piece of Ruby code:

while file.gets
	print if ~/third/ .. ~/fifth/
end

This code reads all lines of a file, and as soon as one line matches the string “third” it starts printing all the following lines - until a line matches the string “fifth” (this is what the “..” operator does - it acts like a toggle switch).

But how does it do that? There are no variables involved whatsoever!

The code works because several ruby functions use global variables by default if no other parameters are given: "file.gets" saves its result in the global variable $_, the "~" operator can match against $_, and if "print" is called with no argument it prints $_.

Something very essential is hidden here: How the data flows through the program. A better - and still very succinct - solution would be:

while line=file.gets
	puts line if line=~/third/ .. line=~/fifth/
end

Conclusion

Less code is better - unless it hides something essential about the solution. Make sure that programmers who use your framework or library can create succinct solutions. Don’t force them to write boilerplate code or configuaration files where defaults would do.

Think about one of your favourite frameworks or libraries. Does it force you to create boilerplate code or does it enable you to create succinct, elegant solutions?