Merge lp://qastaging/~ghugesss/xpad/code_refactor into lp://qastaging/xpad

Hi Sagar,

I went through most of the code changes.
Some things I dislike, some things I like.
Let's see if we can agree on the parts.
I summarize below what I would like to see different.
Feel free to disagree and explain,

1. Split and group changes (and merge requests)

When working with other developers, in general it is better to produce small changes.
And if the changes are bigger, than at least group the different changes together.
In this merge proposal there are many different changes, with some I agree (which I would like to merge) and some I disagree, which I would like to request fixing.

Splitting the changes also makes it easier to find issues introduced by changes. It also makes it easier to undo a change.

So my request is to split the different changes. Below I try to do a start, since I discuss each group of changes by subject.

2. Order of includes

Agree totally. I would like to merge this directly.

3. Improving head guards

I Agree totally. I would like to merge this directly.

4. Improving function declarations by G_BEGIN_DECLS and G_END_DECLS

I Agree totally. I would like to merge this directly.

5. Removal of function prototypes by reordering functions

I am in a split here.
I agree that it is nicer and easier to maintain if these are removed.
I disagree since it sometimes make readability and therefore maintainability harder.

So, only if the readability of the code stays more or less the same, I am in favor of this. Two examples:

I do like the removal of the forward declaration in xpad-pad-group.c

I dislike reading the xpad-pad.c and xpad-app.c from the bottom to the top (instead of the other way around), and therefore I don't like this to be changed.

6. Reformatting of function parameters, each parameter on a new line.

I strongly dislike this. In my opinion this makes reading the code much harder.

I guess it comes from the old-fashioned Linux kernel coding rule: 80 character limit. I used to dislike it and I still dislike it. These days almost each developer has a screen with at least 200 characters if not 500.

Only when the function declaration becomes extremely long, breaking this line in two or three pieces might be better.

7. Reformatting of function and return type on a new line.

I guess this is better. This might be my Java coding habit from the old days.

/* good */
static void
xpad_undo_class_init (XpadUndoClass *klass)

/* bad */
static void xpad_undo_class_init (XpadUndoClass *klass)

I prefer the one defined by me as 'bad', but I don't think it changes readability a lot and the code conforms to the best practice.

***

In general, best practices are good, but are not the law. In my opinion if you have a good reason to disagree with the best practice, it is okay.

For me, most of the disagreements above have to do with readability and maintainability. And since I (we) are maintaining the software, I like to do this as easy as possible.

Again, everything is open for discussing.

Nevertheless, I would like you to start with discussion point 1.
Then I can merge all the subjects we agree on and we can discuss the others after that.

Cheers,
Arthur.