[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] reindenting the tree, choosing a formater

From: N
Subject: [GNUnet-developers] reindenting the tree, choosing a formater
Date: Sat, 7 Sep 2019 19:00:30 +0000

Continuing a conversation which happened offlist and in IRC,
following my last commits which touched about half of everything.

> > I propose that to never have so much noise again
> > in commits, that I do a re-indent commit for everything?
> Sure, assuming you're talking about using Florian's uncrustify style.

Oh? I thought we would be using clang-format.
Do you know how much it differs in style? I've used
clang-format in my hook. I can run uncrustify on the

With NetBSD we had a gsoc project this year to port our coding style
to clang-format, maybe we can look into this with gnunet as well,
see if we can gather what's required to get a clang-format for gnunet
going (even if it's just tiny pieces added to it not an entire style),
possibly for gsoc or before that?

Now a problem I see, as monologued on IRC, is that we "advocate" 2
different tools with different format outcomes. I use clang-format
because it's part of the bootstrap script and I have it integrated
in emacs when I use emacs.

When I format the tree with uncrustify, I get a minor difference to
the clang-format files. This is expected, but we also buy into a
some kind of "eternal motion", Sisyphusarbeit. Will we support clang-format
or will we support uncrustify? Having both makes no sense unless they are
identical. clang-format will always change what uncrustify did, and
uncrustify will always change what clang-format did. This doesn't reduce
the major distraction from work.

I mentioned netbsd gsoc work, here is the link to what was added to
clang-format upstream:

I don't mean to choose one over the other, we could adjust clang-format
to uncrustify as much as possible and analyze what's missing to get
clang-format to the point where it produces identical output.

We don't use canonical gnu coding style afair, but we could still
have this as an improvement to gnu style in clang-format, and override
the rest.

Immediate actions:
1. improve our clang-format file
2. analyze what's missing in clang-format for our style
3. temporarily stop using clang-format(?) or
3. use uncrustify

reply via email to

[Prev in Thread] Current Thread [Next in Thread]