Richard Sargent wrote > No. Please, really no. As much as I appreciate (and share) the passion for Smalltalk, you did not AFAICT address my reasoning for not applying the no-acronym *guideline* in this case, namely:
>> Since the argument IIUC is that "a >> general user won't know the domain well enough to understand the >> acronym", >> would they understand "abstractSyntaxTree"?! That, to me, is as opaque as >> the acronym for one not acquainted with the domain, and may buy us little >> at the cost of a good amount of extra typing. Richard Sargent wrote > a disambiguation page with a lengthy list IMHO this is irrelevant. My proposal included a method comment, which would provide the google-able term, as well as potentially a good enough summary that one wouldn't have to leave the image. The fact that the method belongs to CompiledMethod is the disambiguation. The internet is meaningless and flat compared to the context and structure of a ST image. Richard Sargent wrote > Do not use comments embedded *inside* methods to cover for naming the > method badly… Also, if one Googles an acronym How is a harder-to-type thing that the user doesn't understand but is easier to google better than a comment that gives the necessary context right in the image? My ideal image would avoid the need to Google as much as possible, suggesting a comment either way, so nothing lost. There's nothing inherently "bad" about an acronym. For example, no one's been banging down the door to rename "JPEGReadWriter" to "JointPhotographicExpertsGroupReadWriter". In that case, it's because the acronym is so well-known, but what I'm asking whether #ast is a similar candidate for exception because it is so unknown (i.e. compiler domain-specific) that a user is likely to know either the term and the acronym or neither. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
