On Wed, Jul 13, 2011 at 12:54 PM, Colin Patrick McCabe <colin.mccabe@xxxxxxxxxxxxx> wrote: > On Wed, Jul 13, 2011 at 11:59 AM, Yehuda Sadeh Weinraub > <yehudasa@xxxxxxxxx> wrote: >> On Wed, Jul 13, 2011 at 11:21 AM, Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote: >>> On Wed, Jul 13, 2011 at 10:52 AM, Yehuda Sadeh Weinraub > [snip class variable naming discussion] > > You seem to have two objections to the proposed naming. One is that > you don't like the trailing underscore. That is fine-- I like the "m_" > prefix better myself. > > The second is that you don't want "mixed code." I really don't > understand this objection. We have "mixed code" right now... there are > some classes currently use m_ prefixes, some that use underscore > prefixes, and some that use none of the above. There are some people > using the exact same variable names for class variables and local > variable names-- like the example that I gave-- and relying on the C++ > shadowing rules. I don't see how any reasonable person can read that > kind of code and not feel confused and frustrated. Hmm.. I might have not been clear enough. I said that introducing this now won't fix anything as we have enough code that doesn't follow these rules to dim it ineffective. Moreover, introducing it now as a rule, will just add further confusion for people who'd read the code and assume certain things about the coding style. >> >> The same goes here. Default parameters *may* bite, yes. But they're >> also an important tool that can ease up development and make code look >> much more concise and readable. > > I want to quote the discussion included in the Google coding standard > here, because it's very well-thought-out: >> Pros: >> Often you have a function that uses lots of default values, but >> occasionally you want to override the defaults. Default parameters allow >> an easy way to do this without having to define many functions for the >> rare exceptions. >> >> Cons: >> People often figure out how to use an API by looking at existing code that >> uses it. Default parameters are more difficult to maintain because >> copy-and-paste from previous code may not reveal all the parameters. >> Copy-and-pasting of code segments can cause major problems when the >> default arguments are not appropriate for the new code. Sorry, it didn't convince me. Copy and pasting of code segments can cause other major problems not related to default parameters. > On Wed, Jul 13, 2011 at 11:59 AM, Yehuda Sadeh Weinraub > <yehudasa@xxxxxxxxx> wrote: >> As usual, I don't think that >> restricting your use of the language because of potential errors is >> the better idea. And please, please don't add a compile flag that'll >> prevent it. > > The whole point of coding standards is to restrict your use of the > language to prevent potential errors. Obviously, we don't want the > standard to be too rigid. But dismissing the idea of a standard is not > helpful. > The standard contains much more than the 3 or 4 items that I pointed at. If any, enforcing a standard without a firm *practical* reasoning is not helpful either. Sometimes a rule of thumb is just a rule of thumb, turning it into an enforced standard is, IMO, one step too far. Don't take me wrong here. I care about errors prevention and preemption as much as you do. However, I think there are better things that we should focus our efforts on. Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
