ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>,
	Alexey Dobriyan <adobriyan@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE-TOPIC] Documentation
Date: Mon, 13 Jul 2015 17:46:46 +0100	[thread overview]
Message-ID: <1436806006.20909.59.camel@infradead.org> (raw)
In-Reply-To: <20150713123750.52d8a14d@gandalf.local.home>

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

On Mon, 2015-07-13 at 12:37 -0400, Steven Rostedt wrote:
> There's been times where I look at other subsystems and wonder WTF a
> function is suppose to do. Perhaps I need to start poking the author 
> of that code to explain it.

That should never happen. It's OK if you just don't know how to do
something (or don't even know if it's possible), and you have to ask or
resort to documentation.

But you, Steven, should *never* find yourself looking at a function and
wondering WTF it does. If a function is complex enough that you need an
explanation, then either:

 1. It should have been made simpler, or 
 2. There should be an explanation *right* there in the C file.

Those should be caught in review. Too often, I think, we allow opaque
code to get merged.

I'm guilty of it myself. And I've also suffered from it. Sometimes,
with a few years in between, I have even inflicted this pain on
*myself* :)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

  reply	other threads:[~2015-07-13 16:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-12 22:38 Peter Hüwe
2015-07-12 23:15 ` Julia Lawall
2015-07-14 11:59   ` Mauro Carvalho Chehab
2015-07-13  9:47 ` Alexey Dobriyan
2015-07-13 16:01   ` Randy Dunlap
2015-07-13 16:37   ` Steven Rostedt
2015-07-13 16:46     ` David Woodhouse [this message]
2015-07-13 17:35       ` Steven Rostedt
2015-07-13 19:22         ` Peter Hüwe
2015-07-13 19:28       ` Peter Hüwe
2015-07-13 17:42     ` Jason Cooper
2015-07-13 18:11       ` Steven Rostedt
2015-07-14  3:56         ` Zefan Li
2015-07-13 19:25       ` Peter Hüwe
2015-07-13 22:10       ` Laurent Pinchart
2015-07-13 17:45   ` Jonathan Corbet
2015-07-13 19:46     ` Peter Hüwe
2015-07-14  2:36       ` Jonathan Corbet
2015-07-14  8:40         ` Laurent Pinchart
2015-07-14 11:19           ` Daniel Vetter
2015-07-14 12:43         ` Mauro Carvalho Chehab
2015-07-14 12:53           ` Jonathan Corbet
2015-07-14 13:57           ` Laurent Pinchart
2015-07-14  6:44       ` Johannes Berg
2015-07-13 19:20   ` Peter Hüwe
2015-07-13 23:01     ` Laurent Pinchart
2015-07-13 17:05 ` Lai Jiangshan
2015-07-13 17:42 ` Jonathan Corbet

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=1436806006.20909.59.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=adobriyan@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=ksummit-discuss@lists.linuxfoundation.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