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