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