My own programming style convention for most languages

I write code mainly in R, and from times to times, in C, C++, SAS, bash, python, and perl. There are style guides out there that help make your code more consistent and readable to yourself and others. Here is a style guide for C++, and here is Google’s style guide for R and here is Hadley Wickam’s guide for R. For R, I agree more with Google’s style guide than Hadley Wickam’s because I absolutely hate typing the underscore (personal preference) and because Google’s style guide seems more related to that of the C++’s guide. Style guides differ by languages because the languages are different (restrictions on names, etc.).

My brain goes crazy if I have to remember and apply multiple styles, so I want to use a convention that I can use consistently for all languages. This boils down to refraining from using special characters such as “-”, “.”, and “_” in names as these characters can have special meaning in different languages. Here it goes:

• constants: the letter k or n followed by a description. For example, kConstant or nSim.
• variable names: description words where the first word is lower case and every subsequent words are lower case but with an upper case first letter. For example, varBeta1 for variance of beta1.
• function names: a verb followed by description words, with each word capitalized except. For example, savePlot and computeGRhoGamma. This is the same as the variable names. I originally was going to follow the Google R style guide instead of the C++ style guide, but opted for the latter because the reasoning made sense: the distinction is obvious based on syntax when a function is called (has parentheses and possibly arguments).
• function arguments: depending on the type of argument, use the variable names or function names style for each. To help distinguish an argument that takes in a function, the argument should begin with f if it takes in a function. For example, drop=TRUE and fSummarize=summarizeDefault.

When breaking these conventions lead to a better understanding of the code (easier on the brain), I will not hesitate to break them. For example, using i, j, k as iterator variables, using na.rm as functional argument in R, or rKM for a function that draw random numbers from a Kaplan-Meier survival curve.

Now, if only I can just magically transform all of my own code into this convention. I’m going to really hate going back to old code that doesn’t follow my own style, especially when they refer to code in packages that I will update according to my new convention.