Re: [PATCH 4/6] cli: intialize crypto structure in show and reply
authorJani Nikula <jani@nikula.org>
Thu, 17 May 2012 20:23:15 +0000 (23:23 +0300)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:47:11 +0000 (09:47 -0800)
06/22b01bf2fdd46c6fda3b38eb5d09ade90b5ae7 [new file with mode: 0644]

diff --git a/06/22b01bf2fdd46c6fda3b38eb5d09ade90b5ae7 b/06/22b01bf2fdd46c6fda3b38eb5d09ade90b5ae7
new file mode 100644 (file)
index 0000000..98bed82
--- /dev/null
@@ -0,0 +1,115 @@
+Return-Path: <jani@nikula.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 884B2431FAF\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 13:23:22 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id ucmiBoS3hk8L for <notmuch@notmuchmail.org>;\r
+       Thu, 17 May 2012 13:23:22 -0700 (PDT)\r
+Received: from mail-lpp01m010-f53.google.com (mail-lpp01m010-f53.google.com\r
+       [209.85.215.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id AEEED431FAE\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 13:23:21 -0700 (PDT)\r
+Received: by lagu2 with SMTP id u2so1798814lag.26\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 13:23:18 -0700 (PDT)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+       d=google.com; s=20120113;\r
+       h=from:to:cc:subject:in-reply-to:references:user-agent:date\r
+       :message-id:mime-version:content-type:x-gm-message-state;\r
+       bh=zwHp2Bzuodw8XZydajIAkMnIgWbWjTl9Z25mh2sPq5M=;\r
+       b=f+tTyD3+xjp5I6PfXuVgLmvnts445dPHFNpPRgYU/KYBxR10iPFaCyiOJUQU5p0xoG\r
+       BxNt9R4JmQKBhlyUiGe3v1en/z1Ty/wxQKx2B8BaNE2kBG1UOLX9j187JsRwo6JrN7KC\r
+       s45PgruiZi3aZk3rrfBRoAsLWKktxT6XC/rKDSXEbQdzBjlNh9XZW/hiUdmyc0o8wxBW\r
+       9ZZLn3618KBAbXY82UQEYlE2250o3vsmiXsuFNKAkAakIFb1YqvPbtQUokbuFuIWXNbG\r
+       wC0ycqrhjjR9k0lLRj8ur0XidWCWYrF5YOJZg801l1Glr5Ep9Cgp268vuBj3xDbuQoC7\r
+       Qaig==\r
+Received: by 10.112.54.37 with SMTP id g5mr3607407lbp.104.1337286198745;\r
+       Thu, 17 May 2012 13:23:18 -0700 (PDT)\r
+Received: from localhost (dsl-hkibrasgw4-fe50dc00-68.dhcp.inet.fi.\r
+       [80.220.80.68])\r
+       by mx.google.com with ESMTPS id lv13sm9179774lab.8.2012.05.17.13.23.16\r
+       (version=SSLv3 cipher=OTHER); Thu, 17 May 2012 13:23:17 -0700 (PDT)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>\r
+Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
+In-Reply-To: <87aa16daeq.fsf@servo.finestructure.net>\r
+References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-2-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-3-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-4-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-5-git-send-email-jrollins@finestructure.net>\r
+       <8762bvi70k.fsf@nikula.org>\r
+       <877gwaeve1.fsf@servo.finestructure.net>\r
+       <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
+       <87aa16daeq.fsf@servo.finestructure.net>\r
+User-Agent: Notmuch/0.13+13~gc259b9a (http://notmuchmail.org) Emacs/23.3.1\r
+       (i686-pc-linux-gnu)\r
+Date: Thu, 17 May 2012 23:23:15 +0300\r
+Message-ID: <87396yimks.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Gm-Message-State:\r
+ ALoCoQmH9QAwfRRHtIk6JyukvgaIdlaibzpWHoU+mCkQCW4JEyBiKvYBUwcV/qtRuosHLTGntEg7\r
+Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 17 May 2012 20:23:22 -0000\r
+\r
+On Thu, 17 May 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
+> On Thu, May 17 2012, Jani Nikula <jani@nikula.org> wrote:\r
+>> The values are not undefined, they are properly initialized, and we can\r
+>> count on it. For sure, not maybe. If you want to explicitly set them for\r
+>> clarity, it's a matter of taste. Personally I find it too verbose, but then\r
+>> again notmuch code is generally fairly verbose.\r
+>\r
+> I want them explicitly set for clarity, as well as safety.  Code is\r
+> meant to be read by humans, not computers.  Brevity is not always a\r
+> virtue if it sacrifices clarity.  It's much nicer to have the defaults\r
+> clearly stated in the initialization, than to force the reader to\r
+> understand how the initialization works and to interpret what that means\r
+> for the current case.  I also don't think it's safe to assume that the\r
+> variables will be always be "properly" initialized in your favor in\r
+> perpetuity.  It's much safer to explicitly set them to what you want\r
+> them to be rather than just assume they'll be set correctly.\r
+\r
+In short, when you read enough code, having everything explicitly stated\r
+becomes a burden. It's explicit, but you have to read it all, even when\r
+there really is no need to.\r
+\r
+>> If you insist on it, please at least drop the extra temp crypto\r
+>> variable, and initialize the struct in one initializer.\r
+>\r
+> I don't see why this matters either.  Again, I think this is just a\r
+> matter of taste.  I would rather the code be verbose where clarity\r
+> requires it, rather than always trying to make the code as terse as\r
+> possible.\r
+\r
+You introduce an extra variable that every reader of your code has to\r
+track down to realize that it's only ever used once to initialize\r
+another variable. You make code harder for other people to read.\r
+\r
+I have now offered my review and opinions on the matter; I will not\r
+pursue this discussion further.\r
+\r
+\r
+BR,\r
+Jani.\r