
On Dec 11, 2009, at 11:37 PM, Johannes Laire wrote:
On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe
wrote: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf
Compare:
someCoolFunc fstParam sndParam fooBarBazQuux some_cool_func fst_param snd_param foo_bar_baz_quux
In the first one, it's easy to see that there are 4 identifiers. But, at least for me, the second one is significantly harder to read; spaces and underscored are too similar.
To me the gaps in the second one were clear and distinct. In any case, it's not clear that you *need* to "see that there are 4 identifiers". You need to see the *first* identifier, and then you need to see the second, &c, but let's face it, how often do you need to count the words in a sentence at a glance? And what good does it do to know there are four identifiers if you have to go back with a magnifying class to tell what the identifiers mean? I wrote a little program to search for runs of identifiers without intervening newlines or other tokens. I fed it 56,322 lines of Haskell from various sources. Here's the distribution: Len Tally iCap iCap is the average number of internal 1 84,474 0.21 capital letters in all of the words in 2 27,092 0.32 a run. 3 9,273 0.44 4 3,176 0.45 5 866 0.49 6 165 0.47 7 87 0.36 8 98 0.73 9 42 0.36 10 9 0.22 11 5 0.20 12 7 0.71 13 1 0.00 The longest run was "j then Q i xs ys j else Q j ys xs i" which would be the same under any word separation variant. We see from the "iCap" column that on the whole, the average number of internalCapitals per run is less than one. Looking in some detail at the runs with 4 words, I found that the typical pattern is someHairyGreatFunctionName i x xs with a touch of if okToProceedWith x then In fact, out of 3,176 runs with four words, 2,144 of them didn't have any internal capitals in the first place, so would not be at all affected by a change in word separation style. Having examined the remaining 1032 cases with some care, I honestly couldn't find any cases whose readability was worsened by by underscore separation. Don't forget, some of the arguments are constructors, and using underscore (or hyphen) separation makes it *easier* to see them, because they no longer look like parts of identifiers.