On Oct 28, 2007, at 9:06 AM, Shawn O. Pearce wrote:
Steffen Prohaska <prohaska@xxxxxx> wrote:
On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
Steffen Prohaska <prohaska@xxxxxx> writes:
@@ -213,6 +215,7 @@ int cmd_rev_parse(int argc, const char **argv,
const char *prefix)
{
int i, as_is = 0, verify = 0;
unsigned char sha1[20];
+ char* real_name = 0;
Pointer sign '*' in git sources go next to the name not the
type, as:
char *real_name = NULL;
I know and I tried hard to follow this convention, although
I think its the wrong choice ;)
Oh, hmm...
char* a, b;
What's the type of b? If you said "char*" you're wrong.
I know. Obviously, you need a combination of conventions.
- '*' is part of the type; put it there.
- Only define a single variable per statement.
My combined rule avoids your question. I typically use C++,
which make the second rule easier to follow, because you
defer defining variables until you really need them. There's
no need to save space at the start of the function block by
defining several variables in a single line.
Git's style of putting the * next to the name makes it far easier to
spot these sort of typing problems. At least that's my take on it.
Let's stop this discussion here. I'm not proposing to change the
rules. I'll follow the git coding conventions when submitting
patches to git, even if it's sometimes hard for me. I already packed
as much as possible in my editor configuration. Unfortunately,
I can't teach vim to always place the '*' correctly. At least I
don't know how to do this.
Steffen
-
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
