I'd like to raise the issue of a capitalization convention for naming objects in R. Almost everything in R used to be lowercase but recently there is increasing use of mixed upper/lower case to define names. There is potential for using the capitalizations to make code more self explanatory, but only if a consistent system is used. In Java, capitalization is used to indicate the type of object. Names of methods are capitalized except for the first word (e.g., geneNames), names of classes are fully capitalized (e.g., ExprSet), names of data objects are all lowercase, and names of libraries have their own conventions but normally with lowercase letters. A programmer can recognize the type of object in many cases simply from the name. In R, Java capitalization has started to be used for formal generic functions, but the point of the convention is being lost because the same capitalization is being used for classes, non-generic functions, package names and even function arguments. Naming is not always done consistently and different conventions seem to be used by different people, so within Bioconductor we have classes, functions, arguments, and packages with lots of different capitalization styles. One cannot predict what capitalization style will be used for a given object, so capitalization is on the way to being a complication rather than a clarification. Here is a suggestion for a convention, which people can shoot down if they like: Classes: full capitalization, e.g., ExprSet, AffyBatch, MarrayNorm Generic functions: lower case first word, e.g., maNorm, normalize, rma, geneNames Non-generic functions: lowercase, possibly with dot separaters Members of data classes: lowercase, possibly with dot separaters Function arguments: lowercase, possibly with dot separaters Packages: lowercase, e.g., affy, marraynorm Cheers Gordon

> I'd like to raise the issue of a capitalization convention for naming > objects in R. Almost everything in R used to be lowercase but recently > there is increasing use of mixed upper/lower case to define names. There is > potential for using the capitalizations to make code more self explanatory, > but only if a consistent system is used. Another discussion of this issue is in Henrik Bengtsson's contribution to the DSC-2003. He describes some rules and tools that optionally enforce such conventions. To find it, just Google DSC-2003 and go to working papers/drafts. I don't feel a strong need for such a convention at present, but voluntary adoption of such a convention can be supported if we post a "voluntary coding convention" document somewhere on the site. If it turns out that this is a valuable set of rules, and software tools that aid in achieving compliance are available, then we might consider using this convention for package evaluation and maintenance. Examples of productivity benefits or references on this would be of interest. One alternative perspective is that a universal convention is not necessary, but consistent coding practices within packages can be encouraged. The author can state his/her own convention explicitly for the package.