colin@pdn.UUCP (Colin Kendall) (03/11/88)
In our shop, we have adopted the Smalltalk "standard" of using embedded
capitals in class names, variable names, etc., as in StandardSystemView.
From most of the public domain code that I have seen, this seems to
be fairly universal. I find it highly annoying and counter-productive
for many, many reasons.
The proponents state that it makes the code easier to read; and it does,
butnotverymuch. It occurred to me that in German, words are formed
from other words without embedded capitals; I never had much trouble
reading German on this account, and I doubt that Germans do.
Does anybody know of any shops where this "standard" is not followed? Any
comments from Germany?
--
Colin Kendall Paradyne Corporation
{gatech,akgua}!usfvax2!pdn!colin Mail stop LF-207
Phone: (813) 530-8697 8550 Ulmerton Road, PO Box 2826
Largo, FL 33294-2826goldfain@osiris.cso.uiuc.edu (03/18/88)
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.
johnson@uiucdcsp.cs.uiuc.edu (03/18/88)
I find nothing wrong with the Xerox style for names. I would very much dislike long names with no separators, regardless of what the Germans do. It is probably better to use a separator character (I_use_underscore_in_C) but capital letters are satisfactory. Although this makes it easier to mispell a name, it is only a minor drawback in Smalltalk, because the compiler catches all undefined variables and lets the programmer fix them immediately.
goldfain@osiris.cso.uiuc.edu (03/23/88)
Now that I've thought about it for a bit, I think there is no solution to the embedded-capitals-causes-naming-errors problem. Anything you do to improve readability will cause possible name-matching errors, whether you separate parts of long names with spaces, underscores, capitals, etc. On the other hand, if you do not put any of these in, there will be a loss of readability, which can result in different kinds of errors. I think everyone just has to deal with this tradeoff however they prefer. One thing that certainly does help, as Prof. Johnson noted, is an active checker with spelling-correction suggestions whenever a name is undefined. This has caught and easily corrected every capitalization error I can remember making when programming in Smalltalk.
ard@pdn.UUCP (Akash Deshpande) (03/23/88)
In article <2472@pdn.UUCP>, colin@pdn.UUCP (Colin Kendall) writes: > In our shop, we have adopted the Smalltalk "standard" of using embedded > capitals in class names, variable names, etc., as in StandardSystemView. Smalltalk parser smartly omits space in such symbol declarations as # fred (= #fred). But spaces are permitted in symbols. Thus, ' fred' asSymbol is the symbol # fred. (Try ' fred' asSymbol asString printIt). Thus, StandardSystemView could be represented in the system as a symbol 'Standard System View' asSymbol. Of course, it will be most counter productive to put all these ''s and asSymbols in text. But maybe a special key/mode could be designated to enter symbols in. There is the problem then of reading correctly Standard System View as one symbol as opposed to two or three. This can be solved by having the system put all non-message name symbols in one font and all message name symbols in another font. I am sure the system has enough basis to develop this tool. Akash -- Akash Deshpande Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!ard Mail stop LF-207 (813) 530-8307 o P.O. Box 2826 (813) 535-3987 h Largo, Florida 34649-2826
alan@pdn.UUCP (Alan Lovejoy) (03/24/88)
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. Suppose you can't remember whether a variable was "smalltalk" or "small_talk". This leads you to ask whether it was one word or not. But there is often no answer that is clearly correct. In super_deluxe_subsystem, it is hard to say whether the next-to-last "s" starts a new word. So the result is that incorrectly spelled variables occur ("super_deluxe_sub_system"), and even using embedded capitals instead of underscores won't solve this problem!! The problem could be solved by having the compiler ignore the capitalization of identifiers (or ignore underscores), but that leads to even worse problems. --alan@pdn
ken@pdn.UUCP (Ken Auer) (03/24/88)
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."
GUTFREUND@CS-UMASS.ARPA ("Steven H. Gutfreund") (03/25/88)
Since the advantages/disadvantages to the various concatenation schemes
(embeddedCapitals, hyphenation, straight concatenation) are all basically
marignal in nature, I would suggest that one should not take an absolutist
position. That is, one should neither try and convice the world that one
position is correct, or more importantly, one should not adopt a permanent
fixed standard for all of ones own code.
What do you say? Why shouldn't I adopt a personal standard for myself.
Isn't this a free country and I have the right to self-determination
(note use of hypen). Yes, but in an environment such as smalltalk, where
a major factor in the success of the environment is its homogeneity,
and transparency - the consistant usage of a one metaphoric system
throughout all layers and levels of the system, one does not what to
stack a heterogenous layer of using a different metaphor on top
of the system. I would argue strongly for maintaining this metaphoric
coherence with respect to any application layered on smalltalk.
Work within the basic structure provided by the window system, pop-up
menus, etc. unless there is a more than marginal advantage to your
scheme (e.g. maybe you would like to use pull-down menus, or shuffle
menus instead of pop-up menus. If so, make sure this transformation
is comprehensive throughout the environment).
- gutfreund@cs.umass.edu (via csnet/phoneNet)
gutfreund@cs-umass.arpa (via arpanet/milnet)
steveg@umass.bitnet (via bitnet)
yechezkal-shimon@benDovid.haLevi (via gabbai)ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) (03/26/88)
In article <12100008@osiris.cso.uiuc.edu> goldfain@osiris.cso.uiuc.edu writes: > >Now that I've thought about it for a bit, I think there is no solution to the >embedded-capitals-causes-naming-errors problem. Anything you do to improve >readability will cause possible name-matching errors, whether you separate >parts of long names with spaces, underscores, capitals, etc. This is exactly why the name separator stuff might best be handled by a programming environment, not the compiler/interpreter itself. A potential drawback is that you might end up limiting For example, if uppercase is 'reserved' bu the programming environment as a possible 'long-word-separator' attribute, then you may lose the ability to use uppercase in program symbols. [but maybe these should be represented internally by something other than character strings anyway, like a tagged number (so that the intepreter/compiler doesn't have to do parsing in addition to its other duties.] Ideally, the user preference could be whatever they're most comfortable with, so a symbol displays as AVeryLongWord to users who prefer that style, or a_very_long_word, or just averylongword for those with a lot of patience. Comments? -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA