The most extreme thing that could possibly work

I’ve recently gotten used to the idea that extreme ideas are an important part of learning.  It seems that when trying to understand an idea, it helps to consider the idea in its most extreme form. 

For example, consider the idea of coding in C# with Short Methods.  I think most developers would agree with the statement “I like to keep my functions from getting too long.”  We came across a function that was 1000 lines long, and were pretty scared of that one.  I know many devs who use a screenful as a maximum – if you can see the whole function at once, that goes a long way to helping you understand it. 

When I say “I like my functionst to be really short,” I think people assume I mean like 10 lines long.  10-line methods should be easy to handle, right?

What about 5 lines?  At this point, most traditional developers are sure that I can’t write anything interesting.

What about 1 line?  I’m serious.  I have to say “I’m serious” because most people think the idea is crazy.  They are sure that you can’t write software that actually does anything if you only get one line per method.  But I challenge you to take the idea seriously.  Explore what it would be like to write mostly single-line methods. 

Even if you don’t write this way in the future, you will have learned something important.  When you’re working on an n-line method, you will know how to answer the questions:

  • How could I could make this method shorter?

  • Should I make this method shorter?

That is, it’s important to fuly explore the extreme case if you want to make the right decision about the normal case.

So, when I propose No Private Methods, that’s because it’s the most extreme thing I could think of.  I want to know what that looks like, so that I know when I’ve got the right set of private methods.

Kent Beck talks about this a bit in the first XP book. We know that Code Reviews are a good thing, so why not do them all the time?  That’s Pair Programming.  Similar statements can be made about most of the rest of XP.

Can you make most classes have only a single field?  Or a single ctor?  Or a single method besides the ctor?  What happens when you do?  Do you learn anything interesting along the way?


Comments (22)

  1. "One line" is a bad metric. Here’s what happens if you do that:

    Your code looks worse and worse, as you inevitably try to cram more info into the line:

    public string Hash(string s)


    return Convert.ToBase64String(new MD5CryptoServiceProvider().ComputeHash((System.Text.Encoding.UTF8.GetBytes(s))));


    And the output is a lot worse too. IIRC, The compiler outputs stack based code instead of using locals. I actually benchmarked this code a while ago, and it was slower this way than doing it using a few locals (and the resulting IL was a bit larger).

    So you get:

    1: Harder to read code.

    2: Harder to debug code (see greggm’s WebLog)

    3: (Maybe) larger code.

    As well, this doesn’t work very well if you need error handling.

    I just don’t see how trying to conserve lines any more than usual is going to help at all. All I see it doing is stopping coders from making things extra clear.

    Of course, you could just remove the newlines — would that count? 😉

  2. Andy says:

    The point isn’t to write methods that only contain one line. The point is to think about doing so – what would happen *if* all your methods were one line long? This is the farthest that you can take the concept of "how small should my methods be", since it obviously doesn’t make any sense to have methods with zero lines.

    If you don’t consider this case, then why did you "stop" by making all of your methods 5 lines? Or 10? Or some other arbitrary number?

  3. I worked with a self trained C guy once. His idea of good code was the smallest footprint you could have. Well this resulted in code that was very compact, but few besides him could read it.

    I know that you are not saying this, but it is the danger.

    On the whole I agree with you. I like short functions. One purpose. Self describing/commenting code. I frequently run metrics analysis on my code, just validate myself. I like to keep my cyclomatic complexity under 6 (switch statements are the gotcha’s) and my line count low. But I find that if I stick to one purpose, the line count is usually automatically handled.

  4. Do you find that when you learn something new, you use it everywhere?

    I have. I need to check myself sometimes. There are times when the latest technique I learned, just should be put back on the bookshelf. But on the whole I am a better programmer because I apply those sometimes in appropriate tools. I guess it is my way of learning their limits and uses.

  5. David Cottrill says:

    Be careful — I can tell you from personal experience with Perl one-liners that you are on the path to perdition… 😉

  6. Jesse Ezell says:

    Just about the only worthwhile one line methods are function overloads, because of C#’s wonderful lack of default parameters :-).

    It is far more important to understand that methods are about small, logical units of work than it is to break them up into 1 liners. You are focusing on the wrong problems if you are counting the lines of code in your methods.

  7. Darrell says:

    David – no kidding! I used to write recursive perl programs that would scrub my entire web site (university web site), and the only interesting stuff happened on 1 line! Yikes!

    But Jaybaz(?) has a good point. It’s like the old game show "Name that tune", where people bid down the number of notes they need to figure out a song. The really good people could win it in 1 note! It teaches you to concentrate to figure out what exactly is the minimum needed to accomplish your goal. Challenging conventional thinking, thinking outside the box, and all that blah blah blah. 🙂

  8. e says:

    rex onliner

  9. The most extreme thing that could possibly work

  10. Darren Oakey says:

    I go with the idea of no duplication…. at all.. Which does lead to lots of one line functions – but often, you then realise these functions you use a hell of a lot – you put them in your common libraries, and suddenly the world all gets better again.

    My rule is simple: you do it once, fine. Twice, optional. Three times NO

    For example –

    F1: if ( myString.Instr(subString)!=-1) …

    F2: if ( theString.Instr(stringToFind)!=-1) …

    that’s not good – time for

    bool StringContains( string stringToCheck, string stringToFind)

    {return stringToCheck.InStr( stringToFind)!=-1;}

    And immediately

    a) your code looks better

    if ( StringContains( myString, subString))

    b) you have something you can use in lots of places, and will work with different implementations of string in the future

    c) you have something that when you find odd situations (what do we do with null strings?) – (what do we do with empty strings?) – you can solve the problem across the board.

    Yes – this means that my code is littered with one line functions, but a few points:

    1) each time I do this, the actual raw _size_ of my code gets smaller

    2) you would be surprised at how many of these one line functions don’t stay one line!

    3) every time I fix a problem or enhance one of the functions, the code improves _across the board_

    So – basically, don’t set out to design functions this way (I go with the rule one screenful is utter max for a function, including comments) – but also don’t permit any code duplication – anywhere – and you automatically evolve quite an elegant structure – I guarantee it 🙂

  11. Sean says:

    Here’s the most compact, semi-useful code I know of:

    DVD Decrypt

    The program takes a five-byte title key on the command line (five decimal numbers in least to most-significant order, separated by colons) and an MPEG 2 Program Stream VOB file on stdin, and outputs a decrypted version of the VOB file. For example: to play a movie whose title key is 0xcd302010fe, do: cat file.vob | perl -I 254:16:32:48:205 qrpff | extract_mpeg2 | mpeg2dec –

    #!/usr/bin/perl # 472-byte qrpff, Keith Winstein and Marc Horowitz <>

    # MPEG 2 PS VOB file -> descrambled output on stdout.

    # usage: perl -I <k1>:<k2>:<k3>:<k4>:<k5> qrpff

    # where k1..k5 are the title key bytes in least to most-significant order


    b=map{ord qB8,unqb8,qT,_^$a[–D]}@INC;s/…$/1$&/;Q=unqV,qb25,_;H=73;O=$b[4]<<9





  12. jaybaz [MS] says:

    My favorite was the 3 lines of perl that implemented encryption strong enough to be classified as a munition, and therefore illegal to export.

    I have trouble grokking the notion of "export of software". Somehow it seems meaningless.

  13. One of my favorite bloggers as of late is Jay Bazuzi (rss), who works on the Visual C# IDE team at Microsoft. Give him a read; he’s got some posts that are sure to melt your brain, such as "no…

  14. Chad Myers says:

    Uh oh, jaybaz, Sean just made this weblog illegal! The MPAA will be coming to confiscate your computer soon. Run!

  15. Sean says:

    *hangs my head* sorry man! 😉

  16. Hi,

    You will get effect of huge function on another level. We use functions and classes to bring stucture to our code. When every function is one-line long they become similar to each other because they are of the same length. This will make Your code homogenous like assembler but with much longer statements.

    Aleksei Guzev