All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
	"Randall S. Becker" <rsbecker@nexbridge.com>
Subject: Re: Automatic code formatting
Date: Mon, 11 Jul 2022 14:17:40 +0100	[thread overview]
Message-ID: <0c07f6ca-d52a-f285-56cc-1b673f7d98fb@gmail.com> (raw)
In-Reply-To: <YstJl+5BPyR5RWnR@tapette.crustytoothpaste.net>

Hi brian

On 10/07/2022 22:50, brian m. carlson wrote:
> Most projects written in languages like Rust or Go use an automatic
> formatter.  In Go's case, the formatter is specifically stated to be a
> fixed style that is nobody's favourite, but because there's an automatic
> formatter, everybody just uses it.  Personally, I don't love our coding
> style now (I'm a 4-space person in C), but I would love it a lot more if
> I didn't have to think about it.  I am substantially less picky about
> what the style is than that we have an automated tool to tidy our code,
> and I'm okay with us producing the occasional slightly suboptimal style
> for the improved efficiency we get.
 > [...]
 > I should note that we already have a .clang-format file, so we can
 > already use clang-format.  However, we cannot blindly apply it because
 > it produces output that is not always conformant with our style.  My
 > proposal here is to define our style in terms of the formatter to avoid
 > this problem.

I agree it is lovely not to have to think about the style rules when 
writing code for a project that has an automatic formatter. As Junio 
said I think it would take a bit of work to persuade clang-format to 
match our style and I'm concerned that adopting the style it produces 
now would lead to a lot of churn. Below is an example taken from [1] 
that shows one area for improvement. At the moment its struct formatting 
seems inconsistent (one struct ends up with one field per line and the 
second has more than one field per line with a completely different 
indentation to the first) and I'm not sure we want it reformatting the 
whole definition when a new member is added. When Han-Wen Nienhuys 
submitted that patch I did have a brief play with the clang-format rules 
to try and improve it but didn't get anywhere.

Best Wishes

Phillip

[1] 
https://lore.kernel.org/git/2c2f94ddc0e77c8c70041a2a736e3a56698f058c.1589226388.git.gitgitgadget@gmail.com

@@ -3173,30 +3282,31 @@ static int files_init_db(struct ref_store 
*ref_store, struct strbuf *err)
  	return 0;
  }

-struct ref_storage_be refs_be_files = {
-	NULL,
-	"files",
-	files_ref_store_create,
-	files_init_db,
-	files_transaction_prepare,
-	files_transaction_finish,
-	files_transaction_abort,
-	files_initial_transaction_commit,
-
-	files_pack_refs,
-	files_create_symref,
-	files_delete_refs,
-	files_rename_ref,
-	files_copy_ref,
-
-	files_ref_iterator_begin,
-	files_read_raw_ref,
-
-	files_reflog_iterator_begin,
-	files_for_each_reflog_ent,
-	files_for_each_reflog_ent_reverse,
-	files_reflog_exists,
-	files_create_reflog,
-	files_delete_reflog,
-	files_reflog_expire
-};
+struct ref_storage_be refs_be_files = { NULL,
+					"files",
+					files_ref_store_create,
+					files_init_db,
+					files_transaction_prepare,
+					files_transaction_finish,
+					files_transaction_abort,
+					files_initial_transaction_commit,
+
+					files_pack_refs,
+					files_create_symref,
+					files_delete_refs,
+					files_rename_ref,
+					files_copy_ref,
+
+					files_write_pseudoref,
+					files_delete_pseudoref,
+
+					files_ref_iterator_begin,
+					files_read_raw_ref,
+
+					files_reflog_iterator_begin,
+					files_for_each_reflog_ent,
+					files_for_each_reflog_ent_reverse,
+					files_reflog_exists,
+					files_create_reflog,
+					files_delete_reflog,
+					files_reflog_expire };
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index 4458a0f69cc..8f9b85f0b0c 100644
--- a/refs/packed-backend.c
+++ b/refs/packed-backend.c
@@ -1641,29 +1641,19 @@ static int packed_reflog_expire(struct ref_store 
*ref_store,
  }

  struct ref_storage_be refs_be_packed = {
-	NULL,
-	"packed",
-	packed_ref_store_create,
-	packed_init_db,
-	packed_transaction_prepare,
-	packed_transaction_finish,
-	packed_transaction_abort,
-	packed_initial_transaction_commit,
-
-	packed_pack_refs,
-	packed_create_symref,
-	packed_delete_refs,
-	packed_rename_ref,
-	packed_copy_ref,
-
-	packed_ref_iterator_begin,
-	packed_read_raw_ref,
-
-	packed_reflog_iterator_begin,
-	packed_for_each_reflog_ent,
-	packed_for_each_reflog_ent_reverse,
-	packed_reflog_exists,
-	packed_create_reflog,
-	packed_delete_reflog,
-	packed_reflog_expire
+	NULL, "packed", packed_ref_store_create, packed_init_db,
+	packed_transaction_prepare, packed_transaction_finish,
+	packed_transaction_abort, packed_initial_transaction_commit,
+
+	packed_pack_refs, packed_create_symref, packed_delete_refs,
+	packed_rename_ref, packed_copy_ref,
+
+	/* XXX */
+	NULL, NULL,
+
+	packed_ref_iterator_begin, packed_read_raw_ref,
+
+	packed_reflog_iterator_begin, packed_for_each_reflog_ent,
+	packed_for_each_reflog_ent_reverse, packed_reflog_exists,
+	packed_create_reflog, packed_delete_reflog, packed_reflog_expire
  };

  parent reply	other threads:[~2022-07-11 13:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-10 21:50 Automatic code formatting brian m. carlson
2022-07-10 22:08 ` Junio C Hamano
2022-07-10 22:13 ` rsbecker
2022-07-11  0:58   ` brian m. carlson
2022-07-11  1:28     ` rsbecker
2022-07-11 16:53       ` Elijah Newren
2022-07-11 20:15         ` Ævar Arnfjörð Bjarmason
2022-07-11 21:19           ` Elijah Newren
2022-07-11 11:37 ` [RFC PATCH 0/4] make headway towards a clean "clang-format" Ævar Arnfjörð Bjarmason
2022-07-11 11:37   ` [RFC PATCH 1/4] Makefile: add a style-all targets for .clang-format testing Ævar Arnfjörð Bjarmason
2022-07-11 11:37   ` [RFC PATCH 2/4] .clang-format: Add a BitFieldColonSpacing=None rule Ævar Arnfjörð Bjarmason
2022-07-11 22:42     ` brian m. carlson
2022-07-11 22:52       ` Junio C Hamano
2022-07-12  6:56       ` Ævar Arnfjörð Bjarmason
2022-07-11 11:37   ` [RFC PATCH 3/4] .clang-format: do not enforce a ColumnLimit Ævar Arnfjörð Bjarmason
2022-07-11 21:37     ` Junio C Hamano
2022-07-12  7:03       ` Ævar Arnfjörð Bjarmason
2022-07-11 22:39     ` brian m. carlson
2022-07-11 22:46       ` Junio C Hamano
2022-07-11 23:05         ` Eric Sunshine
2022-07-11 23:30           ` Junio C Hamano
2022-07-11 11:37   ` [RFC PATCH 4/4] .clang-format: don't indent "goto" labels Ævar Arnfjörð Bjarmason
2022-07-11 21:04     ` Junio C Hamano
2022-07-12  6:55       ` Ævar Arnfjörð Bjarmason
2022-07-11 13:17 ` Phillip Wood [this message]
2022-07-11 13:21   ` Automatic code formatting Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c07f6ca-d52a-f285-56cc-1b673f7d98fb@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=rsbecker@nexbridge.com \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.