On Mon, Feb 22, 2016 at 11:22:48AM +0100, Matthieu Moy wrote: > > Idea for microprojects. If you compile using gcc with -Wshadow, it > > spots local variables that shadow another local or global variables. > > These are usually bad because it makes it's easy to make mistakes when > > changing the code. > > I hade a look an a few instances of the warning, and all of them were > bad (sometimes even suspicious, I wouldn't be surprised if we found real > bugs hunting these down). I looked at a handful, too, and many looked fine (e.g., shadowing an overly-broadly-named global parameter with a function parameter). Not that I'm against squelching them. There's definitely potential for confusion, and I won't be surprised either if there's a real bug lurking in there (which we can't find because of the number of false positives). But... > > _If_ you agree shadow vars are bad and should be exterminated, > > 'master' has 94 warnings spreading over 49 files. A student can pick > > _one_ file and try to fix all warnings in that file. There are many > > possible approaches (rename, combine vars, change scope, even > > restructure/kill global vars..), plenty of room for discussion. > > +1. > > Are there counter-arguments to this? I agree that there are a lot of different ways to resolve each instance, and it will vary from case to case. I think the original point of a microproject was to do something really easy and not contentious, so that the student could get familiar with all of the other parts of the cycle: writing a commit message, formatting the patch, posting to the list, etc. It seems like this has a high chance of frustrating students as they get embroiled in back-and-forth review. I dunno. Maybe it should be marked with a star as a "challenge" microproject. :) -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html