Changes between Version 21 and Version 22 of CodingRules

11/29/13 10:51:08 (8 years ago)



  • CodingRules

    v21 v22  
    990. Curly braces are *always* on a single empty line (this gives a clear structure to the code), although in *switch* statements. No comments on the line with the opening brace. Put them above (e.g. the if-clause) or below in the next line.
    10100. *goto* is a no-go, it breaks the structure of the code (check google for details)
     110. Global variables are a no-go as well. Look at root, then you know what I am talking about.
     120. Try to avoid filling the global namespace with enums. Make them class members or create a namespace for them.
    11130. In switch statements the *case* label is on the same level as the *switch*. The corresponding code or brackets are indented.
    12140. There is only one command per line. In if conditions the command to be executed is always on a new line, the *else* is always on it's own empty line.
    46480. Try to avoid code repetitions. Invent a new function instead.
    47490. Move code to their own function, If otherwise the structure gets too complicated. A typical example is `"MyClass *ptr = new MyClass; CallFunction(ptr); delete ptr;"` is much easier than `"MyClass *ptr = new MyClass; if (...) { delete ptr; return; } if (...) { delete ptr; return; } delete ptr;"` In a similar case `"int i = Find(a);"` with something like `"int Func(int a) { for (int i=0; i<n; i++) { if (x[i]==a) return i; if (x[i]==a+1) return a+1; ... } return -1; }"` then if you try to construct the same with breaks and variables declared outside of the for-scope.
     500. If you have many almost identical lines one after each other, try to align them to make the common structure immediately visible. Don't overdo that! A lot of unexpected spaces if they don't make things immediately apparent confuse and do not help at all.
     510. Code is not a piece of art. Try to avoid to format things because they seem to look nice or fancy. Keep your formatting functional and make sure it represents the structure of your code.
     520. Although pointers are a concept you need to learn and understand, loops over iterators (or pointers) are usually easier(!) to read and the possibility to misunderstand their meaning is much less, because the access of the data is not indirect (and every indirection can be doing something different than what you expect) and limits are better defined. {{{begin()}}} and {{{end()}}} are very clear, while {{{0}}} and {{{5}}} can be everything, even wrong. In many cases also optimization and hence performance will profit.
     530. Do not complain about strange construction, sometimes they are a matter of necessity to get performance!
     540. The is a lot of fancy coding stuff which looks complicated at first, but there are very good reasons that they were invented (like iterators). These are mostly performance issues and readability. Note: Readability does not mean that it is easy to read, it means that when you read it once, after it there is no doubt left what it is doing!
     550. Do not re-invent the wheel. Check the STL, it is worth. There are a lot of helpful function (find minima, find maxima, sort, ...) They are often more efficient that what you could program yourself, and again: Somebody reading it does not need to understand your code (which might even be wrong) *and* has the advantage of an existing documentation.
     560. When you use a container, carefully think what makes its use efficient. Check the documentation (Just search e.g. for std::list, I am sure the first answer will contain what you are looking for). A good C++ documentation contains all info you need (does searching in the container scale with N or Nlog(N)? Is access constant or does it scale with the number
     57of elements? Do you need random access or is linear access enough?)
     580. Note that when Mars was coded, STL weren't yet available in all Compilers, especially templates weren't. So try to be conservative using that to keep consistency (most STL stuff can be replaced by root stuff, see TMath or TCollection)
    116127Root is sometimes a bit tricky... here are a few coding rules or hints.
    118 0. Try to avoid using global pointers (gRandom is an exception)
     1290. Try to avoid using global pointers (gRandom is an exception). Properly store the pointers to the objects you created instead (e.g. {{{file=new TFile(...); file->...}}} instead of {{{new TFile; gFile->...}}}
    1191300. *same* is TGraphs is done by omitting the A (A means *with axis*)
    1201310. Try to avoid pointers, use objects, except if you add them to a root list.