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.
>
>>
>>>
>>>>
>>>> * Naming > Constant Names:
>>>>
>>>> Google uses kSomeThing for constants. We prefere SOME_THING.
>>>>
>>>> * Naming > Function Names:
>>>>
>>>> Google uses CamelCaps. We use_function_names_with_underscores().
>>>>
>>>> Accessors are the same, {get,set}_field().
>>>>
>>>> * Naming > Enumerator Names:
>>>>
>>>> Name them like constants, as above (SOME_THING).
>>>>
>>>> * Comments > File Comments:
>>>>
>>>> Don't sweat it, unless the license varies from that of the project (LGPL2) or
>>>> the code origin isn't reflected by the git history.
>>>>
>>>> * Formatting > Conditionals:
>>>>
>>>> - No spaces inside conditionals please, e.g.
>>>>
>>>> if (foo) { // okay
>>>>
>>>> if ( foo ) { // no
>>>>
>>>> - Always use newline following if:
>>>>
>>>> if (foo)
>>>> bar; // okay
>>>>
>>>> if (foo) bar; // no, usually hardler to visually parse
>>>>
>>>>
>>>>
>>>>
>>>> The following guidelines have not been followed in the legacy code,
>>>> but are worth mentioning and should be followed strictly for new code:
>>>>
>>>> * Header Files > Function Parameter Ordering:
>>>>
>>>> Inputs, then outputs.
>>>
>>> I generally agree, just that there's a class of strcpy like functions
>>> that put the destination first. This usually makes sense when you have
>>> multiple functions that do similar things with varied input
>>> parameters:
>>>
>>> char *strcpy(char *dest, const char *src);
>>>
>>> char *strncpy(char *dest, const char *src, size_t n);
>>>
>>> So in both cases, dest and src are the first and second parameters,
>>> which looks more consistent.
>>
>> Well, nothing is set in stone. There are always exceptions if it
>> really makes sense. If you are designing a function patterned after
>> strcpy or whatever, making it "look like" strcpy probably makes a lot
>> of sense.
>>
>>>
>>> And there's also the case of using default values, which usually
>>> (though not always) applies to the input parameters. Enforcing strict
>>> input before output ordering wouldn't work there.
>>
>> Well, the Google document says not to use default parameters because
>> "they obscure the interface."
>> So that is a non-issue.
>>
>> Check out commit 6e2b594b3329cb08bf54cd325776b236f2e6c4f1 for an
>> example of how default parameters can really bite.
>>
>
> 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.
>
> Decision:
> Except as described below, we require all arguments to be explicitly
> specified, to force programmers to consider the API and the values they
> are passing for each argument rather than silently accepting defaults they
> may not be aware of.
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.
regards,
Colin
--
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
