[PATCH] D37264: [Docs] Update CodingStandards to recommend range-based for loops

Aaron Ballman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 29 10:29:02 PDT 2017


aaron.ballman added inline comments.


================
Comment at: docs/CodingStandards.rst:944
 
-  for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
-    if (BinaryOperator *BO = dyn_cast<BinaryOperator>(II)) {
+  for (auto &I : BB) {
+    if (auto *BO = dyn_cast<BinaryOperator>(&I)) {
----------------
asb wrote:
> majnemer wrote:
> > javed.absar wrote:
> > > aaron.ballman wrote:
> > > > majnemer wrote:
> > > > > I'd replace the `auto` with `Instruction &`.
> > > > We should clarify this in the coding standard, because I've always understood we generally *want* to use `auto` in range-based for loops, for brevity (and because the type is generally immediately apparent from the container).
> > > In some complicated cases not using 'auto' improves code understanding. I have had cases where well established reviewers of llvm have recommended me not to  use 'auto' in their review comment.
> > The most consistent rule I have seen is that we want to avoid repeating ourselves. `auto` makes a lot of sense if you just made a `std::vector<int>` a few lines up and are now iterating. If you have some `FancyContainerTy`, it is less awesome to use `auto` as it is not clear what it is you get from iterating it.
> For `FancyContainerTy` sure, but my impression is it's quite common to use auto for simple container types where the types are well known to the average LLVM developer. e.g. Instructions in a BasicBlock, BasicBlocks in a Function.
Agreed that we use `auto` primarily when the type is explicitly spelled out in the initialization. I was mostly interested in clarification around range-based for loops. The above is an example where I usually recommend `auto` because I thought that was the direction we had picked back when the C++11 discussion happened. If that's an incorrect understanding, I think we really should clarify the coding standard so I have something more concrete to point to.


https://reviews.llvm.org/D37264





More information about the llvm-commits mailing list