All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jeff King <peff@peff.net>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 3/9] diff: avoid generating unused hunk header lines
Date: Fri, 2 Nov 2018 12:50:05 -0700	[thread overview]
Message-ID: <CAGZ79kZb7kMhkE=EWRtR8tpkQCY3v8rWugHvq24TFGHpBxmygw@mail.gmail.com> (raw)
In-Reply-To: <20181102063606.GC31216@sigill.intra.peff.net>

> +/*
> + * Can be used as a no-op hunk_fn for xdi_diff_outf(), since a NULL
> + * one just sends the hunk line to the line_fn callback).
> + */
> +void discard_hunk_line(void *, long, long, long, long, const char *, long);

Recently we had the discussion on style and naming things.
On the one hand I don't know what these 4 different longs do,
so I'd wish for some descriptive variable names in here.
On the other hand the docs explain clearly why I don't need
to care (a no-op ignores all of the parameters, no need
to take care of their order)

So to revive that discussion, I would strongly prefer
to have *some* names there, for the sake of a
simply described coding style without many exceptions
(especially those exceptions that rely on judgement).

Today I read [1], which describes the analog in the
mechanical world: To evolve and have more impact
you need tighter requirements on some parts. And
I would roughly translate that to our use case as
not having to worry about style (it's ironic I even type
out this email... if we could just run clang format or
some other tightly controlling formatter/linter, I'd be
much happier as our focus should be elsewhere,
such as UX or performance).

Apart from that, I read the whole series, and found
it a pleasant read.

Thanks,
Stefan

[1] https://www.nybooks.com/articles/2018/10/25/precision-accuracy-perfectionism/

  reply	other threads:[~2018-11-02 19:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-02  6:31 [PATCH 0/9] saner xdiff hunk callbacks Jeff King
2018-11-02  6:35 ` [PATCH 1/9] xdiff: provide a separate emit callback for hunks Jeff King
2018-11-02  6:35 ` [PATCH 2/9] xdiff-interface: provide a separate consume " Jeff King
2018-11-02  6:36 ` [PATCH 3/9] diff: avoid generating unused hunk header lines Jeff King
2018-11-02 19:50   ` Stefan Beller [this message]
2018-11-02 20:15     ` Jeff King
2018-11-03  0:32       ` Junio C Hamano
2018-11-02  6:36 ` [PATCH 4/9] diff: discard hunk headers for patch-ids earlier Jeff King
2018-11-02  6:37 ` [PATCH 5/9] diff: use hunk callback for word-diff Jeff King
2018-11-02  6:38 ` [PATCH 6/9] combine-diff: use an xdiff hunk callback Jeff King
2018-11-02  6:39 ` [PATCH 7/9] diff: convert --check to use a " Jeff King
2018-11-02  6:39 ` [PATCH 8/9] range-diff: " Jeff King
2018-11-02  6:40 ` [PATCH 9/9] xdiff-interface: drop parse_hunk_header() Jeff King
2018-11-02 11:48 ` [PATCH 0/9] saner xdiff hunk callbacks Junio C Hamano

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='CAGZ79kZb7kMhkE=EWRtR8tpkQCY3v8rWugHvq24TFGHpBxmygw@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.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.