Aleksei Guzev was scared by my last post on readability vs writability.
I think what might have scared Aleksei (feel free to correct me if I am wrong Aleksei) is the thought that the results of this study would be used to make a case for adding a Count property to the DataReader class and removing the ability to iterate through the contents of the class with IEnumerator. Far from it – no such case was made as a result of this study and none will be. What the study shows though is that for some developers, using IEnumerator will not be as intuitive as it will be for others. Therefore, it is worth considering how to make this more obvious to those developers. For example, Intellisense in Visual Studio could highlight particular programming patterns or tasks that a class supports (it might show a list of tasks in addition to a list of methods such as ‘Iterate through the contents of myDataReader’) such that when the user selects one of these tasks, the code to accomplish this is generated and inserted into the editor. In this case, Intellisense might generate code that creates an instance of an enumerator, sets it to the first element, creates the loop to MoveNext through the enumerator and calls Current to get each element. The user would then just have to add code to do whatever they wanted with each element.
You can think of other examples – for instance, classes that implement IDisposable might have a task called ‘Use this resource’ (or some better wording…) that would automatically insert a using statement if the language supported it, or would just insert the appropriate Dispose call.
Other alternatives to addressing the usability feedback would be to make supporting these tasks much clearer in the documentation. The key point that I am trying to make though, is just because participants find some tasks in an API usability study difficult, doesn’t always mean that the only solution available to you is to change the API. In many cases it is, but there are times when changing the API to address usability feedback won’t always be the best thing to do.