[gst-devel] GStreamer needs a maintainer

[Benjamin Otte]

On Wed, 17 Dec 2003, Thomas Vander Stichele wrote:

> Personally, I think it can't be too hard to establish some sort of
> methodology to make this work better.  The real question is, what do we
> want to commit to ?  If all of you are going to say "cvs commit messages
> are fine for me, I don't care what people expect from us wrt. decent
> changes information", then there's not much I can do, and I will let it
> drop.
>
I would totally like using Changelogs. It's just that writing ChangeLog
entries by hand is annoying the hell out of me and up until 10 minutes ago
I didn't even know what tools existed to automate that process. I did some
research when I started to hack on Rb, but found nothing I liked.
So I think it comes down to the fact that the GStreamer guys ahve no clues
about tools that help in Changelog generation.
If the people using changelogs would explain what tools they use I'm sure
we'd find tools that would make using changelogs as easy as commit
messages for everyone here.
It's not that I hate changelogs because the name sucks or anything. They
suck because I don't have tools to create them.

> My next question will be wrt. coding style, by the way :) I get sick of
> our ten styles, and I feel we should just make sure everything is
> machine-fixable and run it through indent.  To support your statement,
> I'm going to start by saying "I don't care what the coding style is, but
> pick one that works through indent and is consistent and has enough
> spaces so we don't end up with stuff like if(a+5=2) b=9;else
> printf("dumbass:%d\n",a);", and I'm not ever going to complain about the
> style chosen after that.
>
I can pretty much work with all our coding styles, so I don't really care.
I mostly adapt to how it's written.

But for the argument, my current coding style goes like that (current
because it's not yet final, I'm still to young to have everything figured
out ;)):

void		some_function			(int		arg1,
						 int *		arg2);

void
some_function (int arg1, int *arg2)
{
  gchar *str;

  g_return_val_if_fail (arg1 < 0);

  if (arg1 == 0)
    return;

  if (arg2 != NULL) {
    some_function (arg1 - 1, arg2);
    *arg2 *= arg1;
  } else {
    str = some_pretty_macro_to_format_with_a_very_long_name (
	__LINE__, arg1, NULL);
    g_print (str);
    g_free (str);
  }
}

Some things to note:
- indent is 2, tab is 8.
- Indent function definitions at function name, argument type and argument
name. Indent with tab.
- Use a new line for every argument.
- If I break a line, the next line continues with indent 4.
- use a space after function names, commas or similar.
- function definitions in code have one line for return value, one line
for the function name (for lines that are too long, indent rules apply)
and one for the opnening bracket.
- opening brackets are on the same line
as the stuff they open. Only
exception are functions, they need to be more prominent and therefore get
an extra line for the opening bracket.
- else has both brackets on the same line.
- Only use if without brackets if the whole body of the if command is 1
line long. Always use brackets with "else".
- Use an empty line to seperate different blocks of code. Especially
variable declarations and g_return_if_fail blocks are seperate.

What I haven't figured out yet is what a good width for a file is. 80
characters it quite short IMO, especially when the function names start
getting long. 150 chars is a bit wide though. SOmewhere in between it's
possibly just right.


Have fun arguing about it :)

Benjamin