From: Federico Vaga <federico.vaga@vaga.pv.it>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] trace-cmd: replace show_file() -> show_instance_file()
Date: Tue, 01 Aug 2017 01:27:38 +0200 [thread overview]
Message-ID: <f14378cf956f7be2db965f6f59d04867@vaga.pv.it> (raw)
In-Reply-To: <20170731153539.255ab561@gandalf.local.home>
On Mon, Jul 31, 2017 at 03:35:39PM -0400, Steven Rostedt wrote:
> On Mon, 10 Jul 2017 02:15:35 +0200
> Federico Vaga <federico.vaga@vaga.pv.it> wrote:
>
>> On Friday, July 7, 2017 12:29:35 AM CEST Steven Rostedt wrote:
>> > On Mon, 5 Jun 2017 11:31:18 +0200
>> >
>> > Federico Vaga <federico.vaga@vaga.pv.it> wrote:
>> > > show_file(name) and show_instance_file(&top_instance, name) are
>> > > equivalent.
>> > >
>> > > Remove the show_file() function in order to have a single function for
>> > > this task.
>> >
>> > Actually I find nothing wrong with having a helper function like this.
>> > IIRC, show_file() was first, and then show_instance_file() came later.
>> > There's some files that only exist for the top_instance, and I like the
>> > fact that this is annotated that way.
>> >
>> > I'm curious to know what the benefit of removing show_file() is?
>>
>> The show_file(name) and show_instance_file(&top_instance, name) are
>> equivalent: they do the same thing. By removing `show_file` the
>> developers are
>> forced to use always the same function and being explicit about the
>> instance
>> they want to use.
>>
>> The name `show_file()` is so generic that does not implies
>> automatically that
>> we are accessing the top_instance. This is not even clear by reading
>> the
>> implementation; people must read the other functions used in
>> `show_file()` to
>> understand that their instance scope is always 'top_instance'.
>>
>> So, in my opinion, it makes the code easier to read and more explicit
>> in what
>> is doing without too much effort.
>>
>
> Just an FYI. You'll find lots of these types of helper functions in the
> Linux Kernel. As I'm a Linux Kernel developer, I prefer them ;-)
We are kind of artists: there is always a bit of personal taste
(preferences)
in what we do; that justify our presence instead of an AI (for the time
being) :P
As I said in the other email, I tend to be verbose when something does
not have
an unique interpretation at first sight.
If this is your preference, I will not say anything more and I will not
send a V2
for this patch.
Federico Vaga
prev parent reply other threads:[~2017-07-31 23:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-05 9:31 Minor Code Clean Up Federico Vaga
2017-06-05 9:31 ` [PATCH 1/2] trace-cmd: use asprintf when possible Federico Vaga
2017-07-06 22:25 ` Steven Rostedt
2017-07-10 0:08 ` Federico Vaga
2017-07-25 14:21 ` Federico Vaga
2017-07-31 19:33 ` Steven Rostedt
2017-07-31 23:12 ` Federico Vaga
2017-06-05 9:31 ` [PATCH 2/2] trace-cmd: replace show_file() -> show_instance_file() Federico Vaga
2017-07-06 22:29 ` Steven Rostedt
2017-07-10 0:15 ` Federico Vaga
2017-07-31 19:35 ` Steven Rostedt
2017-07-31 23:27 ` Federico Vaga [this message]
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=f14378cf956f7be2db965f6f59d04867@vaga.pv.it \
--to=federico.vaga@vaga.pv.it \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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 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 NNTP newsgroup(s).