Reading Code Over the Telephone

In my youth I once attended a lecture given by Brian Kernighan on the subject of code quality, which was very influential on my attitudes towards writing legible code. One of the things that Kernighan recommended was to endeavour write code that was so clear that it could be easily read over the phone and understood. Most people find code much easier to comprehend when read than when heard; if you can make it clear enough to be understood when heard, it's probably pretty clear code.

I was reminded of this when I got the following question from a colleague by email:

Subject: Stupid C# 3.0 lambda expression question

How does one read the => operator?

First off, I told my colleague that there are no stupid questions, only stupid people. No stupid people work here, so don't stress about it. This is a perfectly sensible question.

As far as I know, we do not have an "official" line on how to read this operator over the phone. In the absense of any other context, I personally would say c=>c+1 as "see goes to see plus one". Some variations that I've heard:

For a projection, (Customer c)=>c.Name: "customer see becomes see dot name"

For a predicate, (Customer c)=>c.Age > 21: "customer see such that see dot age is greater than twenty-one"

An unfortunate conflation is that the => operator looks a lot like ⇒, the "implies" operator in mathematics. Since => does not have the same semantics as ⇒, it is probably a bad idea to read => as "implies". (x⇒y would have the semantics of !x|y in C#.)

Incidentally, it is a little known fact that VB6 and VBScript implemented the ⇒ operator with the Imp keyword and the ⇔ operator with the Eqv keyword. They disappeared in VB.NET. Where did they go? It is a mystery!

Comments (25)
  1. Greg D says:

    I’ve actually been reading the => operator as "maps to".  Stealing your example:

    Customer see "maps to" see dot age is greater than 21.

  2. Eric Lippert says:

    Good one. Though I’d tend to use "maps to" for one-to-one transformations such as projections, rather than predicates.

  3. Nathan says:

    I call it "rocket ship".

    You probably don’t want to know what I call the :- operator in Prolog…

  4. Wayne Bloss says:

    I read the => operator as: "is used to get" or "are used to get" since items to the left of the operator are used as parameters in the expression that returns something.

    "Customer see is used to get see dot Name."

    (Customer c)=>c.Name

    "Customer see is used to get dot Age is greater than twenty-one."

    (Customer c)=>c.Age > 21

    "int ecks and string ess are used to get ess dot length is greater than ecks."

    (int x, string s) => s.Length > x

  5. mstrobel says:

    (Customer c) => c.Name;

    "[Given|For] Customer see, [return|yield] see dot Name."

  6. mstrobel says:

    Having thought about it a bit more, I’d substitute ‘evaluate’ for ‘return|yield’ to further differentiate it from a precompiled anonymous delegate:

    (Customer c) => c.Name;

    "Given a Customer see, evaluate see dot Name."

  7. Eric Lippert says:

    "Yield’ might be problematic in the future if we ever allow anonymous functions to be iterators. (Which I would dearly like, but is unlikely to happen any time soon.)

  8. I give my vote to "maps to". Mathematically, a function maps values from A to B. In a way, you would rather be saying "customer see is mapped to a string via see dot name" or "customer is mapped to a boolean via see dot age greater 21"

  9. Bryan Watts says:

    +1 for "Given a Customer see, evaluate see dot Name"

    "Maps to" and ilk directly translate to "Select", which is but one of the many uses of lambdas.

  10. Cleve says:

    How about just lambda?

    customer see lambda see dot name

  11. Jonathan says:

    This is one of the reason’s I like VB. Our version Function(c as Customer) C.Name easily translates into "the function of C as Customer returns C dot Name". It is hard to find a VB line that doesn’t read cleanly.

  12. AdamR says:

    Does MSDN count as a source for "official" jargon? It refers to => as "goes to":

  13. Anonymous says:

    It is also hard to write VB lines that are terse.

  14. Kyralessa says:

    I like "yield", but unfortunately C# already has a yield.  I’ve been using "such that" quite a bit, but it doesn’t really work in all cases.

  15. Kyralessa says:

    Oh yeah, and I hate "goes to".  Just sounds weird to me.

  16. Olmo says:

    I usualy translate

    {ParameterList} => {Lambda Body}


    given a {ParameterList}, {Lambda Body}

    with nothing in the middle but a comma.

  17. Anthony Jones says:

    For over a decade (and then some) I’ve written code in VB and I never found a use for Imp or Eqv even when I tried to invent one.  Perhaps thats the reason they’re not in VB.NET 😉

  18. Your method would only work with a C programmer who was on the *exact* same wavelength as you.  Even many C programmers would be clueless as to what you are say.   So like your method abnd logic = FAIL.  

    What if you were reading the same code to a secretary, or your Dilbert managemetn boss, or a high school teenager taking a programming class, or your mother learning to program?  They would have no clue what you were talking about.

    Reading over the telephone, you need to spell it out exactly as its keyboard character names….   below is how I would do it in English, other languages of course would vary to their approapriate keyboard symbol names:

    sea <pause> equals sign <pause> greater than sign <pause> sea <pause> plus sign <pause> one

    I stress the inclusion of pauses of silence, to give the person on the other side to process the symbol in their brain, locate it on the keyboard, and press it, and mainly, to deliminate each individual symbol from the previous and the next, for many symbols are expressed not as a single word (ie, asterix) but as a string of words (ie, greater than symbol)

  19. Eric Lippert says:

    So if you were reading a recipe to someone over the phone, you wouldn’t say "add two tablespoons of baking powder", you’d say "add two T-B-S-P-S of baking powder"?

    My point, and Kernighan’s point, which I seem to not have made very clear, was not about actually solving the problem of reading code over the phone to someone who is not fluent in the language. No one actually has to do that!

    Rather, it was intended to be a thought experiment that makes you think about whether the logic and structure of the code is sufficiently clear that it could be read aloud and understood WITHOUT having to write it down on the other end.

    So, for example, were I to read the code

    for (int i = 0; i < 10 ; ++i) Console.WriteLine(i);

    I’d read that aloud as "for eye from zero to nine, console dot writeline eye". That gets across the meaning of the code, which, after all, is what we’re attempting to communicate. And then when reading it aloud, one might notice that

    foreach(int i in Range(0, 10)) Console.WriteLine(i);

    would ALSO be read aloud the same way. Which is good, because these two blocks of code express the same idea.

    It is precisely those expressions which cannot be read aloud and understood without spelling them out character by character and writing them down on the other end which are sufficiently hard to understand to warrant at least considering rewriting them to be more understandable.  

  20. Stephan Leclercq says:

    Just another "silly" question 🙂 how would you read Python code indentation over the phone ?

  21. Richard says:


    I suppose you could read it how it lexes. So "if a is greater than 5, then foo of a, dedent. bar of a". Though what you say doesn’t have to be a literal transcription of the syntax — I think I’d probably say "end if" or similar…

    As for (Customer c) => (c.Age > 5), I think I’d say "lambda customer see to see dot age greater than five". I might not say the "lambda" if it’s clear what I mean without it.

  22. Parker Hillius says:

    For a predicate, (Customer c)=>c.Age > 21: "customer see such that see dot age is greater than twenty-one"

    I would say "customer c where c dot age is greater than twenty-one"

  23. Tim says:

    So how well does the "c" read over the phone? What does see mean? Vision? Sea? Si (Spanish)? Yes dot name? The Atlantic ocean dot name? Or is it the Gulf of Mexico we’re talking about?

    What is it with lambda expressions (and linq) that dictate that we should start writing unreadable code?

    Do you use variable names like "c" and "s" elsewhere?

    Especially with linq, when I look a query with all those single character variables I have to unnecessarily use extra brain cycles to map what those meaningless single char variables mean. I should be able to understand what every part of a lambda expression is doing without having to go back and map what those variables refer to.

    With intellisense and Resharper there’s just no excuse to be writing code like that.

  24. Rather than place the links to the most recent C# team content directly in Community Convergence, I have

  25. Tom Allen says:

    30 years ago my brother, Mark, worked on a new HP desktop calculator called the 9825.  it had a new feature and a new button with a symbol much like "=>"; he named it the "gazinta" key.  (as in, "goes in to").  Why not create a new name for this feature and call it "gazinta"?


Comments are closed.

Skip to main content