Path: utzoo!mnetor!uunet!steinmetz!ge-dab!codas!pdn!ken From: ken@pdn.UUCP (Ken Auer) Newsgroups: comp.lang.smalltalk Subject: Re: embeddedCapitals Message-ID: <2612@pdn.UUCP> Date: 23 Mar 88 16:45:58 GMT References: <2472@pdn.UUCP> <12100007@osiris.cso.uiuc.edu> Reply-To: ken@pdn.UUCP (0000-Ken Auer) Organization: Paradyne Corporation, Largo, Florida Lines: 112 Keywords: nocapitalizationstinks capitalsGreatlyImproveReadability Summary: Readability overrides minor drawbacks In article <12100007@osiris.cso.uiuc.edu> goldfain@osiris.cso.uiuc.edu writes: > > Colin Kendall notes that the Smalltalk embedded-capital "standard" is not >super-helpful. It has an even worse drawback. Suppose you can't remember >whether a variable was "Smalltalk" or "SmallTalk". This leads you to ask >whether it was one word or not. But there is often no answer that is clearly >correct. In superDeluxeSubsystem, it is hard to say whether the next-to-last >"s" starts a new word. So the result is that incorrectly spelled variables >occur, whereas without the embedded capital standard, there would not be this >problem. If it's just a temporary variable, either way it is readable. If it is a message name, instance variable, etc. (as pointed out earlier) it will almost always be caught (and corrected) by Smalltalk's spelling checker. I admit that having to consider where to capitalize can be an annoyance, but the times such cases occur is insignificant compared to the trouble one would have reading code without capital letters (or some other kind of word separator). I contend that either "superDeluxeSubSystem" or "superDeluxeSubsystem" is much easier to read than "superdeluxesubsystem". Whether or not prefixes cause the first letter of the word its modifying to be capitalized is fairly insignificant as far as readability is concerned, but not capitalizing a prefix preceded by another word is! Although I don't have any studies to prove my point, I can tell you that I never (from day one) had any problem reading standard Smalltalk code (ignoring comments, as many Smalltalk programmers have :-(, but I've almost always had problems reading code that discarded the use of capitals to separate words. Here's a simple test. Which is easier for you to read? atempvariablewithoutcapitalletters vs. aTempVariableWithoutCapitalLetters (smalltalk allcallson: #addsubview:in:borderwidth:) select: [:eachmethod | eachmethod hasnocapitals] vs. (Smalltalk allCallsOn: #addSubView:in:borderWidth:) select: [:eachMethod | eachMethod hasNoCapitals]. If you had little trouble with the uncapitalized version, rewrite a few of your methods (say a class full) taking out the capital letters. Leave it alone a week or so, and then go back and try to read them. Another issue is lack of word separators can sometimes cause ambiguity. I can not think of a time when separators would be used by a Smalltalker while trying to convey the meaning of a variable that would allow ambiguity in the interpretation of that variable (although I'm sure Colin could come up with at least one :-). I can think of several cases where not using capitals does. For a real live example, I ran across the variable: not1mux (Does it mean "not 1 mux" or "no t1-mux") or how about: noton ("not on" or "no ton") prefix ("pre-fix" or "prefix") preference ("p reference" or "preference") asynchronouslink ("asynchrous link" or "a synchronous link") Some of these may seem far fetched, (e.g. "preference") but they serve as examples of the kind of problems you can face when dealing in an application world where words (variables) are constantly being invented by combining words in a programmers mind. If I were writing code to check if there were any reference to a 'p' in a paragraph, my mind set would probably not tell me that "preference" is a word that does not mean "a reference to p". If I'm using word separators, I don't have to worry about what is or is not in my mind set -- the meaning of "pReference" (or "p_reference") is obvious to the casual observer. The first example, "not1mux" was interpreted by me as "no t1-mux" when I first read it, and it took me a while (after looking through an assortment of related methods) to figure out that it meant "not 1 mux". I'm sure the engineer didn't notice that it was ambiguous when he wrote it, and I'm sure he didn't notice it when he read it two days later, but I'm not so sure that he wouldn't notice it if he looked at the code several months later. The only advantages I see of no capitalization (or seperators of any type for that matter) are: 1. less keystrokes 2. not having to figure out whether a word modified by a prefix should be capitalized or not in a certain context. I think a rule (or rules) could be made (we have a few of them in our "standards document") to make #2 even less significant, but it (they) would be a pain to enforce while the standard Smalltalk-80 code is inconsistent at times (e.g. instance variable of View is 'subviews' but to add one you call #addSubView:...). These advantages don't nearly outweigh the advantages of using capitalization, especially when taking into account the fact that Smalltalkers spend much more time reading code than writing (er, typing) it. As Kent Beck wrote in his "Smalltalk Style" (Vol.1 No.1) column "If you make changes which you expect other people to use you must strive to communicate them in the simplest and most palatable manner." Communication is the key here. Using word separators is the best way to communicate the meaning of a variable (or message name). -------------------------------------------------------------------------- Ken Auer Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!ken Mail stop LF-207 Phone: (813) 530-8307 P.O. Box 2826 Largo, FL 34649-9981 "The views expressed above do not necessarily reflect the views of my employer, which by no means makes them incorrect."