Language Readability vs. Writability

In my previous post, I said:

“Unfortunately, language readability is often at odds with writability.”

And

“Generic method type parameters are inferred from the concrete parameters”

Here’s what I’m talking about:

            T F<T>(T t) { return t; }

            void Test()

            {

                  Console.WriteLine(F(1) + 2);

            }

Which overload of Console.WriteLine gets called?

The compiler sees that you’re passing ‘1’ to F(), which is an int. So, the concrete parameter ‘t’ is an int, so the type parameter ‘T’ is an int, so F() returns an int. Add an int to ‘2’ and you get an int. So, we are calling

            public static void WriteLine(int value);

I don’t think that’s immediately obvious from the code, but it sure is easier to write than:

                  Console.WriteLine(F<int>(1) + 2);

The other inference added in C# 2.0 is with delegates. Consider:

            delegate void D();

            void F() { }

            void Test()

            {

                  D d = F;

                  d();

            }

It’s certainly easier to write than:

                  D d = new D(F);

But because it’s inferred, it’s harder to read, both for tools & for devs.

The final point was about ‘foreach’. Today you write:

            void Test(List<int> myList)

            {

                  foreach (int i in myList) { }

            }

But why not let you write:

            void Test(List<int> myList)

            {

                  foreach (i in myList) { }

            }

Can’t the compiler figure out the type of ‘i' for you? Yes, but now you’ve compromised readability:

                  foreach (i in foo.bar(baz(x))) { }

Now, to know the type of ‘i', you have to correctly figure out which overload of ‘bar’ is called, which requires figuring out the correct overload of ‘baz’, too. It could be quite complicated.

Since I’m on the editor team, I think solution lies in an editor. When making a decision about read vs. write, one option is to select easy-to-read, and then use the editor to make it easy to write. For example, a smart editor could infer & insert the type in the ‘foreach’ for you automatically.

Hmm, guess I need to get to work!

Comments

• Anonymous
  July 01, 2004
  The comment has been removed
• Anonymous
  July 01, 2004
  Kevin: I'll check it out.
• Anonymous
  July 09, 2004
  I hope I'm not too late on this comment. In terms of readability vs. writeability, our shop went with readability to extreme ends.
  
  We require that all type names are fully qualified (we don't use the using statement for aliasing namespaces). So, all variable/parameter/return value declarations are fully qualified. We also preface all member items with this. when we refer to them.
  
  The refactoring stuff in the editor looks really exciting. Is it possible to have an options to tell the editor to always use fully qualified type names and to use this. in the code that it writes on our behalf?
• Anonymous
  July 09, 2004
  Never too late!
  
  Jeremey: We'll use the FQN if the 'using' directives aren't there. So, I think you'll be happy with the outcome.
• Anonymous
  July 12, 2004
  The comment has been removed
• Anonymous
  July 12, 2004
  Darren: very interesting. Thanks for taking the time to write it all out.
  
  It'll take my brain a little time to process, for sure.
  
  Oh, and +2 points for referencing Chomsky. :-)
• Anonymous
  May 31, 2009
  PingBack from http://patiochairsite.info/story.php?id=306