git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] clang-format: outline the git project's coding style
Date: Fri, 11 Aug 2017 10:49:58 -0700	[thread overview]
Message-ID: <20170811174958.GB59325@google.com> (raw)
In-Reply-To: <xmqqpoc56x27.fsf@gitster.mtv.corp.google.com>

On 08/09, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> >>> > +# Insert a space after a cast
> >>> > +# x = (int32) y;    not    x = (int32)y;
> >>> > +SpaceAfterCStyleCast: true
> >>> 
> >>> Hmph, I thought we did the latter, i.e. cast sticks to the casted
> >>> expression without SP.
> >>
> >> I've seen both and I wasn't sure which was the correct form to use.
> >
> > We do the latter because checkpatch.pl from the kernel project tells
> > us to, I think.
> 
> Before I forget, there are some rules in checkpatch.pl that I
> deliberately ignore while accepting patches from the list.  
> 
> I appreciate the tool for pointing out overlong lines, but I often
> find them easier to read as-is than split into two lines, as the
> ones the people send in real life rarely excessively exceed the
> 80-col limit.  We also use things like SHA_CTX that trigger "avoid
> camelcase", which I also ignore.
> 
> One thing we probably should standardize is the way the width of
> bitfields in struct is specified.  I think checkpatch.pl wants to do
> 
> 	struct {
> 		unsigned int three_bits : 3;
> 	};
> 

I couldn't find a specific setting for this, but it seems like the
.clang-format file I made wants bit fields to be formatted with spaces
surrounding the ':'.

> with SP around the colon, but our codebase does not always have the
> spaces there, and I see no technical reason not to follow suit, as
> long as we are following most of what checkpatch.pl wants us to do.
> 
> By the way, I do not recall seeing a rule about this in your clang
> format rules.  Can we spell it out in there?
> 
> I also see this:
> 
>     WARNING: __printf(string-index, first-to-check) is preferred over
>     __attribute__((format(printf, string-index, first-to-check)))
> 
> but I think it is specific to the kernel source (the macro is
> defined in include/linux/compiler-gcc.h and expands to the latter),
> so I also ignore it.
> 
> checkpatch.pl also warns a SP immediately before HT, which I do pay

I'm sorry what's 'HT'?

> attention to, as well as trailing whitespaces.  If clang-format can
> be told to check that, I think we would want to have such a rule.

Clang-format by default removes trailing whitespace.

> 
> For a reference, here is a sample set of changes to cache.h to
> squelch most of the warnings and errors checkpatch.pl points out
> that I do not ignore.
> 
>  cache.h | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/cache.h b/cache.h
> index 4e390e6af8..dec807b3b0 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -25,7 +25,7 @@
>  #define platform_SHA_CTX	SHA_CTX
>  #define platform_SHA1_Init	SHA1_Init
>  #define platform_SHA1_Update	SHA1_Update
> -#define platform_SHA1_Final    	SHA1_Final
> +#define platform_SHA1_Final	SHA1_Final
>  #endif
>  
>  #define git_SHA_CTX		platform_SHA_CTX
> @@ -260,7 +260,7 @@ static inline void copy_cache_entry(struct cache_entry *dst,
>  
>  static inline unsigned create_ce_flags(unsigned stage)
>  {
> -	return (stage << CE_STAGESHIFT);
> +	return stage << CE_STAGESHIFT;
>  }
>  
>  #define ce_namelen(ce) ((ce)->ce_namelen)
> @@ -317,7 +317,7 @@ static inline unsigned int canon_mode(unsigned int mode)
>  	return S_IFGITLINK;
>  }
>  
> -#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
> +#define cache_entry_size(len) (offsetof(struct cache_entry, name) + (len) + 1)
>  
>  #define SOMETHING_CHANGED	(1 << 0) /* unclassified changes go here */
>  #define CE_ENTRY_CHANGED	(1 << 1)
> @@ -373,7 +373,7 @@ extern void free_name_hash(struct index_state *istate);
>  #define read_cache_unmerged() read_index_unmerged(&the_index)
>  #define discard_cache() discard_index(&the_index)
>  #define unmerged_cache() unmerged_index(&the_index)
> -#define cache_name_pos(name, namelen) index_name_pos(&the_index,(name),(namelen))
> +#define cache_name_pos(name, namelen) index_name_pos(&the_index, (name), (namelen))
>  #define add_cache_entry(ce, option) add_index_entry(&the_index, (ce), (option))
>  #define rename_cache_entry_at(pos, new_name) rename_index_entry_at(&the_index, (pos), (new_name))
>  #define remove_cache_entry_at(pos) remove_index_entry_at(&the_index, (pos))
> @@ -1483,10 +1483,10 @@ struct checkout {
>  	const char *base_dir;
>  	int base_dir_len;
>  	struct delayed_checkout *delayed_checkout;
> -	unsigned force:1,
> -		 quiet:1,
> -		 not_new:1,
> -		 refresh_cache:1;
> +	unsigned force : 1,
> +		 quiet : 1,
> +		 not_new : 1,
> +		 refresh_cache : 1;
>  };
>  #define CHECKOUT_INIT { NULL, "" }
>  
> @@ -1534,7 +1534,7 @@ extern struct alternate_object_database {
>  	char path[FLEX_ARRAY];
>  } *alt_odb_list;
>  extern void prepare_alt_odb(void);
> -extern void read_info_alternates(const char * relative_base, int depth);
> +extern void read_info_alternates(const char *relative_base, int depth);
>  extern char *compute_alternate_path(const char *path, struct strbuf *err);
>  typedef int alt_odb_fn(struct alternate_object_database *, void *);
>  extern int foreach_alt_odb(alt_odb_fn, void*);
> @@ -1587,10 +1587,10 @@ extern struct packed_git {
>  	int index_version;
>  	time_t mtime;
>  	int pack_fd;
> -	unsigned pack_local:1,
> -		 pack_keep:1,
> -		 freshened:1,
> -		 do_not_close:1;
> +	unsigned pack_local : 1,
> +		 pack_keep : 1,
> +		 freshened : 1,
> +		 do_not_close : 1;
>  	unsigned char sha1[20];
>  	struct revindex_entry *revindex;
>  	/* something like ".git/objects/pack/xxxxx.pack" */
> @@ -1767,10 +1767,10 @@ struct object_info {
>  	union {
>  		/*
>  		 * struct {
> -		 * 	... Nothing to expose in this case
> +		 *	... Nothing to expose in this case
>  		 * } cached;
>  		 * struct {
> -		 * 	... Nothing to expose in this case
> +		 *	... Nothing to expose in this case
>  		 * } loose;
>  		 */
>  		struct {

-- 
Brandon Williams

  reply	other threads:[~2017-08-11 17:50 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08  1:25 [RFC] clang-format: outline the git project's coding style Brandon Williams
2017-08-08 12:05 ` Johannes Schindelin
2017-08-08 17:40   ` Stefan Beller
2017-08-08 18:23     ` Brandon Williams
2017-08-09 22:33       ` Johannes Schindelin
2017-08-09 22:42         ` Stefan Beller
2017-08-10  9:38           ` Johannes Schindelin
2017-08-10 16:41             ` Junio C Hamano
2017-08-10 17:15               ` Brandon Williams
2017-08-10 17:28                 ` Junio C Hamano
2017-08-10 21:30                   ` Brandon Williams
2017-08-11 20:06                     ` Ben Peart
2017-08-14 15:52               ` Johannes Schindelin
2017-09-28 11:41         ` Johannes Schindelin
2017-09-28 17:16           ` Brandon Williams
2017-08-08 17:45 ` Junio C Hamano
2017-08-08 18:03   ` Brandon Williams
2017-08-08 18:25     ` Junio C Hamano
2017-08-09  7:05       ` Junio C Hamano
2017-08-11 17:49         ` Brandon Williams [this message]
2017-08-11 19:00           ` Junio C Hamano
2017-08-09 13:01 ` Jeff King
2017-08-09 14:03   ` Ævar Arnfjörð Bjarmason
2017-08-09 22:53     ` Stefan Beller
2017-08-09 23:11       ` Stefan Beller
2017-08-11 17:52         ` Brandon Williams
2017-08-11 21:18           ` Jeff King
2017-08-12  4:39             ` Junio C Hamano
2017-08-13  4:41               ` Jeff King
2017-08-13 16:14                 ` Ramsay Jones
2017-08-13 16:36                   ` Ramsay Jones
2017-08-13 17:33                   ` Junio C Hamano
2017-08-13 19:17                     ` Ramsay Jones
2017-08-09 23:19       ` Jeff King
2017-08-15  0:40         ` brian m. carlson
2017-08-15  1:03           ` Jonathan Nieder
2017-08-14 21:30 ` [PATCH v2 0/2] clang-format Brandon Williams
2017-08-14 21:30   ` [PATCH v2 1/2] clang-format: outline the git project's coding style Brandon Williams
2017-08-14 22:02     ` Stefan Beller
2017-08-15 13:56       ` Ben Peart
2017-08-15 17:37         ` Brandon Williams
2017-08-14 22:48     ` Jeff King
2017-08-14 22:51       ` Jeff King
2017-08-14 22:54         ` Brandon Williams
2017-08-14 23:01           ` Jeff King
2017-08-16 12:18             ` Johannes Schindelin
2017-08-15 14:28     ` Ben Peart
2017-08-15 17:34       ` Brandon Williams
2017-08-15 17:41         ` Stefan Beller
2017-08-14 21:30   ` [PATCH v2 2/2] Makefile: add style build rule Brandon Williams
2017-08-14 21:53     ` Stefan Beller
2017-08-14 22:25     ` Junio C Hamano
2017-08-14 22:28       ` Stefan Beller
2017-08-14 22:57         ` Jeff King
2017-08-14 23:29           ` Junio C Hamano
2017-08-14 23:47             ` Junio C Hamano
2017-08-15  0:05               ` Brandon Williams
2017-08-15  1:52               ` Jeff King
2017-08-14 21:32   ` [PATCH v2 0/2] clang-format Brandon Williams
2017-08-14 23:06   ` Jeff King
2017-08-14 23:15     ` Stefan Beller
2017-08-15  1:47       ` Jeff King
2017-08-15  3:03         ` Junio C Hamano
2017-08-15  3:38           ` Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20170811174958.GB59325@google.com \
    --to=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).