[parted-devel] avoid printf, when easy to do
David Cantrell
dcantrell at redhat.com
Wed Mar 7 23:30:39 CET 2007
On Wed, 2007-03-07 at 17:01 -0300, Otavio Salvador wrote:
> Jim Meyering <jim at meyering.net> writes:
>
> > Otavio Salvador <otavio at debian.org> wrote:
> >
> >> "Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> writes:
> >>
> >>> Some more printf-like functions replaced by fputs, puts and putchar. I
> >>> have tried to avoid any re-formatting than what was absolutely
> >>> necessary to preserve the formatting of the code after making the
> >>> changes.
> >>>
> >>> Comments?
> >>
> >> Some comments.
> >>
> >>> --- a/libparted/fs/ext2/ext2_inode_relocator.c
> >>> +++ b/libparted/fs/ext2/ext2_inode_relocator.c
> >>> @@ -309,7 +309,7 @@ static int doscan(struct ext2_fs *fs, struct ext2_inode_relocator_state *state)
> >>> }
> >>>
> >>> if (fs->opt_verbose)
> >>> - fprintf(stderr, "\n");
> >>> + fputc ('\n', stderr);
> >>
> >> I don't know if we should or not also change the indentation on the
> >> changed lines. I'm ok with it but I would like to hear from the others
> >> too.
> >>
> >> There're a lot of indentation changes on the patch.
> >
> > I noticed, but didn't say anything about this or other recent patches
> > on the presumption that we'll have to do some global reformatting
> > eventually anyhow. The current situation is untenable.
>
> Yes, I agree that we need to make it global but the problem is when we
> should enforce it. David?
Regarding enforcing formatting standards, I do not want a script to
automatically check commits. There's really no need for something like
that when we could all check each other's patches before commit anyway.
My policy on other projects is to convert tabs to spaces as you go
through the project. I don't really care about going through the entire
code base now and making a huge number of commits to change whitespace.
I'm in favor of cleanups as we hit the file.
If you do make whitespace cleanups, make that be the only commit for
your patch. It's ok to make non-functional commits like whitespace
changes. Don't mix functional changes with non-functional ones.
Jim has suggested we place comments at the bottom of each file to
enforce our coding practices. We can do this for both emacs and vim,
which appear to be our preferred editors. I use vim, personally.
As the coding standard comments are placed at the bottom of the source
file, I view that as a sign that the file has had whitespace cleanups
occur. So if you're going to do that, clean up the file, then commit
the coding style comments at the bottom to mark that file as "DONE".
The coding style comments will basically help us enforce indentation
only. For other things (placement of braces, function declaration
style, etc), we'll just have to converge on agreed-upon coding
practices.
Here's my recommendation for the vim coding comment:
/* vim:set shiftwidth=4 softtabstop=4 noexpandtab: */
--
David Cantrell <dcantrell at redhat.com>
Red Hat / Westford, MA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20070307/1b165613/attachment.pgp
More information about the parted-devel
mailing list