tux-droid-user

[tuxdroid-user] PATCH: For new coding style

[Srikanta P. <sri...@gm...>]

Hi,

As we discussed yesterday on IRC, I'm submitting a patch
to change existing daemon trunk code to follow new coding
style.

Some points to remember:
- Changes almost all the files.
- No functionality changes.
- Lots of changes, so its basically upto the maintainer
to accept/reject.  :-)
- I've changed the existing code to follow the coding-style as
I've documented on the website how-to
(
http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-and-packaging-an-application).

Incase the patch is accepted, lets apply the patch asap, before new
code gets in.

regards,
srikanta

Re: [tuxdroid-user] PATCH: For new coding style

[David B. <da...@ja...>]

On Sat, 10 Mar 2007 16:23:20 +0100, Srikanta Prasanna  
<sri...@gm...> wrote:

> Hi,
>
> As we discussed yesterday on IRC, I'm submitting a patch
> to change existing daemon trunk code to follow new coding
> style.

Hi Srikanta,
Thanks, greatly appreciated.

> Some points to remember:
> - Changes almost all the files.
> - No functionality changes.
> - Lots of changes, so its basically upto the maintainer
> to accept/reject.  :-)

No problem, I applied it loaclly and indeed have to commit it now  
otherwise it will break soon.

> - I've changed the existing code to follow the coding-style as
> I've documented on the website how-to
> (
> http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-and-packaging-an-application).

Now the indenting and spacings look like they should be :-)

In these guidelines, I was surprised to see that you prefer flower braces  
on a new line (#2). That's the way I personally like it but when looking  
at various guidelines I saw that most of the time they prefer and  
recommend the more compact use #1 instead. I'm just concerned many coders  
will prefer #1. What do you think?

#1:
   if (test) {
       // do something
   }

#2:
   if (test)
   {
       // do something
   }

Another point, functions seems to be declared that way:

type
my_function (
     type arg1,
     type arg2,
         )
{
     // body
}

while another common way is

type my_function (type arg1, type arg2)
{
     // body
}

I've seen that the first way was preferred in order to add comments for  
every argument on each line. But if we use doxygen to generate comments,  
we don't really need that as the params should be documented in the  
function comment I think.

I'd like to have some opinions quickly so I can commit the patch if  
everyone seems to agree to the current guidelines or correct it.

Thanks
david

Re: [tuxdroid-user] PATCH: For new coding style

[Srikanta P. <sri...@gm...>]

On 3/11/07, David Bourgeois <da...@ja...> wrote:
>
> On Sat, 10 Mar 2007 16:23:20 +0100, Srikanta Prasanna
> > Some points to remember:
> > - Changes almost all the files.
> > - No functionality changes.
> > - Lots of changes, so its basically upto the maintainer
> > to accept/reject.  :-)
>
> No problem, I applied it loaclly and indeed have to commit it now
> otherwise it will break soon.


Thanks!


> - I've changed the existing code to follow the coding-style as
> > I've documented on the website how-to
> > (
> >
> http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-and-packaging-an-application
> ).
>
> Now the indenting and spacings look like they should be :-)
>
> In these guidelines, I was surprised to see that you prefer flower braces
> on a new line (#2). That's the way I personally like it but when looking
> at various guidelines I saw that most of the time they prefer and
> recommend the more compact use #1 instead. I'm just concerned many coders
> will prefer #1. What do you think?
>
> #1:
>    if (test) {
>        // do something
>    }
>
> #2:
>    if (test)
>    {
>        // do something
>    }


_Personally_, I prefer #2  just to maintain uniformity while using
flower-braces.
That is, while defining a method, we use { in new line. So, why not for all
other
stuff? ;-). Just for sake of uniformity.

Ofcourse, its very true that many prefer #1. That's why, I added
"Recommended"
and "Not Recommended" in the coding doc, instead of "Good" / "Bad" :-)

Infact, we can remove this flower braces stuff from the doc, and let the
contributor
decide what way he wants (just for now ;-).


Another point, functions seems to be declared that way:
>
> type
> my_function (
>      type arg1,
>      type arg2,
>          )
> {
>      // body
> }
>
> while another common way is
>
> type my_function (type arg1, type arg2)
> {
>      // body
> }
>
> I've seen that the first way was preferred in order to add comments for
> every argument on each line. But if we use doxygen to generate comments,
> we don't really need that as the params should be documented in the
> function comment I think.


Yes, even I prefer the second way. Its more common and natural. And doxygen
(I think) expects the documentation in the function header comment. So, we
can
go with the second way.


I'd like to have some opinions quickly so I can commit the patch if
> everyone seems to agree to the current guidelines or correct it.


My part is done :-)

regards,
Srikanta

[tuxdroid-user] Fwd: Re: PATCH: For new coding style

[David B. <da...@ja...>]

Thanks Henrik,

Do other people have problems posting on the list? For those who never  
posted, just give us your opinion so you'll know if it works or not.

------- Forwarded message -------
From: "Henrik Grindal Bakken" <hg...@if...>
To: da...@ja...
Subject: Re: [tuxdroid-user] PATCH: For new coding style
Date: Mon, 12 Mar 2007 13:05:22 +0100

"David Bourgeois" <da...@ja...> writes:

Since you asked for opinions...  I emailed this to you directly (hope
you didn't get two copies now...), because either the sourceforge mail
server or my work mail server refused me to post to the list.

> In these guidelines, I was surprised to see that you prefer flower
> braces on a new line (#2). That's the way I personally like it but
> when looking at various guidelines I saw that most of the time they
> prefer and recommend the more compact use #1 instead. I'm just
> concerned many coders will prefer #1. What do you think?
>
> #1:
>   if (test) {
>       // do something
>   }
>
> #2:
>   if (test)
>   {
>       // do something
>   }

Personally, at least, I prefer #1.

> Another point, functions seems to be declared that way:
>
> type
> my_function (
>     type arg1,
>     type arg2,
>         )
> {
>     // body
> }
>
> while another common way is
>
> type my_function (type arg1, type arg2)
> {
>     // body
> }

I prefer #2 here (actually, I prefer to have the opening brace on the
same line as well, but that's not too common, I think).  I think the
best argument for #2 is that it helps grepping.  If a function has
many arguments, one can always do
type func(type arg1,
           type arg2,
           ...
           type argn)
{

}

I prefer having return type on the same line as the function name no
matter how one place the arguments.  Using doxygen to document
arguments is a better solution than per-argument comments anyway,
IMHO.

Hopefully the tuxen will arrive soon.  Then I guess I have to have a
look at the code myself too :)

Re: [tuxdroid-user] Fwd: Re: PATCH: For new coding style

[Srikanta P. <sri...@gm...>]

On 3/11/07, David Bourgeois <da...@ja...> wrote:
>
> Thanks Henrik,
>
> > Another point, functions seems to be declared that way:
> >
> > type
> > my_function (
> >     type arg1,
> >     type arg2,
> >         )
> > {
> >     // body
> > }
> >
> > while another common way is
> >
> > type my_function (type arg1, type arg2)
> > {
> >     // body
> > }
>
> I prefer #2 here (actually, I prefer to have the opening brace on the
> same line as well, but that's not too common, I think).  I think the
> best argument for #2 is that it helps grepping.  If a function has
> many arguments, one can always do
> type func(type arg1,
>            type arg2,
>            ...
>            type argn)
> {
>
> }
>
>
Another + point for #2 way:
In Vi, to reach the function beginning, one can just to [[.
This works only when the { is on column 1. :-)

Re: [tuxdroid-user] Fwd: Re: PATCH: For new coding style

[Florent T. <ft...@gm...>]

On 3/11/07, David Bourgeois <da...@ja...> wrote:
> Thanks Henrik,
>
> Do other people have problems posting on the list? For those who never
> posted, just give us your opinion so you'll know if it works or not.

Hi.

Test