Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / 06 / 22b01bf2fdd46c6fda3b38eb5d09ade90b5ae7
1 Return-Path: <jani@nikula.org>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id 884B2431FAF\r
6         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 13:23:22 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.7\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id ucmiBoS3hk8L for <notmuch@notmuchmail.org>;\r
16         Thu, 17 May 2012 13:23:22 -0700 (PDT)\r
17 Received: from mail-lpp01m010-f53.google.com (mail-lpp01m010-f53.google.com\r
18         [209.85.215.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
19         (No client certificate requested)\r
20         by olra.theworths.org (Postfix) with ESMTPS id AEEED431FAE\r
21         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 13:23:21 -0700 (PDT)\r
22 Received: by lagu2 with SMTP id u2so1798814lag.26\r
23         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 13:23:18 -0700 (PDT)\r
24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
25         d=google.com; s=20120113;\r
26         h=from:to:cc:subject:in-reply-to:references:user-agent:date\r
27         :message-id:mime-version:content-type:x-gm-message-state;\r
28         bh=zwHp2Bzuodw8XZydajIAkMnIgWbWjTl9Z25mh2sPq5M=;\r
29         b=f+tTyD3+xjp5I6PfXuVgLmvnts445dPHFNpPRgYU/KYBxR10iPFaCyiOJUQU5p0xoG\r
30         BxNt9R4JmQKBhlyUiGe3v1en/z1Ty/wxQKx2B8BaNE2kBG1UOLX9j187JsRwo6JrN7KC\r
31         s45PgruiZi3aZk3rrfBRoAsLWKktxT6XC/rKDSXEbQdzBjlNh9XZW/hiUdmyc0o8wxBW\r
32         9ZZLn3618KBAbXY82UQEYlE2250o3vsmiXsuFNKAkAakIFb1YqvPbtQUokbuFuIWXNbG\r
33         wC0ycqrhjjR9k0lLRj8ur0XidWCWYrF5YOJZg801l1Glr5Ep9Cgp268vuBj3xDbuQoC7\r
34         Qaig==\r
35 Received: by 10.112.54.37 with SMTP id g5mr3607407lbp.104.1337286198745;\r
36         Thu, 17 May 2012 13:23:18 -0700 (PDT)\r
37 Received: from localhost (dsl-hkibrasgw4-fe50dc00-68.dhcp.inet.fi.\r
38         [80.220.80.68])\r
39         by mx.google.com with ESMTPS id lv13sm9179774lab.8.2012.05.17.13.23.16\r
40         (version=SSLv3 cipher=OTHER); Thu, 17 May 2012 13:23:17 -0700 (PDT)\r
41 From: Jani Nikula <jani@nikula.org>\r
42 To: Jameson Graef Rollins <jrollins@finestructure.net>\r
43 Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
44 In-Reply-To: <87aa16daeq.fsf@servo.finestructure.net>\r
45 References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net>\r
46         <1337205359-2444-2-git-send-email-jrollins@finestructure.net>\r
47         <1337205359-2444-3-git-send-email-jrollins@finestructure.net>\r
48         <1337205359-2444-4-git-send-email-jrollins@finestructure.net>\r
49         <1337205359-2444-5-git-send-email-jrollins@finestructure.net>\r
50         <8762bvi70k.fsf@nikula.org>\r
51         <877gwaeve1.fsf@servo.finestructure.net>\r
52         <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
53         <87aa16daeq.fsf@servo.finestructure.net>\r
54 User-Agent: Notmuch/0.13+13~gc259b9a (http://notmuchmail.org) Emacs/23.3.1\r
55         (i686-pc-linux-gnu)\r
56 Date: Thu, 17 May 2012 23:23:15 +0300\r
57 Message-ID: <87396yimks.fsf@nikula.org>\r
58 MIME-Version: 1.0\r
59 Content-Type: text/plain; charset=us-ascii\r
60 X-Gm-Message-State:\r
61  ALoCoQmH9QAwfRRHtIk6JyukvgaIdlaibzpWHoU+mCkQCW4JEyBiKvYBUwcV/qtRuosHLTGntEg7\r
62 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
63 X-BeenThere: notmuch@notmuchmail.org\r
64 X-Mailman-Version: 2.1.13\r
65 Precedence: list\r
66 List-Id: "Use and development of the notmuch mail system."\r
67         <notmuch.notmuchmail.org>\r
68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
69         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
71 List-Post: <mailto:notmuch@notmuchmail.org>\r
72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
74         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
75 X-List-Received-Date: Thu, 17 May 2012 20:23:22 -0000\r
76 \r
77 On Thu, 17 May 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
78 > On Thu, May 17 2012, Jani Nikula <jani@nikula.org> wrote:\r
79 >> The values are not undefined, they are properly initialized, and we can\r
80 >> count on it. For sure, not maybe. If you want to explicitly set them for\r
81 >> clarity, it's a matter of taste. Personally I find it too verbose, but then\r
82 >> again notmuch code is generally fairly verbose.\r
83 >\r
84 > I want them explicitly set for clarity, as well as safety.  Code is\r
85 > meant to be read by humans, not computers.  Brevity is not always a\r
86 > virtue if it sacrifices clarity.  It's much nicer to have the defaults\r
87 > clearly stated in the initialization, than to force the reader to\r
88 > understand how the initialization works and to interpret what that means\r
89 > for the current case.  I also don't think it's safe to assume that the\r
90 > variables will be always be "properly" initialized in your favor in\r
91 > perpetuity.  It's much safer to explicitly set them to what you want\r
92 > them to be rather than just assume they'll be set correctly.\r
93 \r
94 In short, when you read enough code, having everything explicitly stated\r
95 becomes a burden. It's explicit, but you have to read it all, even when\r
96 there really is no need to.\r
97 \r
98 >> If you insist on it, please at least drop the extra temp crypto\r
99 >> variable, and initialize the struct in one initializer.\r
100 >\r
101 > I don't see why this matters either.  Again, I think this is just a\r
102 > matter of taste.  I would rather the code be verbose where clarity\r
103 > requires it, rather than always trying to make the code as terse as\r
104 > possible.\r
105 \r
106 You introduce an extra variable that every reader of your code has to\r
107 track down to realize that it's only ever used once to initialize\r
108 another variable. You make code harder for other people to read.\r
109 \r
110 I have now offered my review and opinions on the matter; I will not\r
111 pursue this discussion further.\r
112 \r
113 \r
114 BR,\r
115 Jani.\r