From: Michael Witten <mfwitten@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message
Date: Mon, 20 Apr 2009 00:38:50 -0500 [thread overview]
Message-ID: <b4087cc50904192238j744f353dtf5f6a616cada8cd8@mail.gmail.com> (raw)
In-Reply-To: <7vskk4nlrg.fsf@gitster.siamese.dyndns.org>
On Sun, Apr 19, 2009 at 20:42, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> + die "Server does not support STARTTLS: " . $smtp->message . "\n"
>> + unless $smtp->code == 220;
>
> ...
> But the following, which is equivalent to what you did, is inexcuable.
>
> do this;
> do that;
> do something unusual
> if some condition that rarely holds true;
> do some other thing;
>
> When your eyes and brain are coasting over this segment of code, your
> thought process needs to stumble and hiccup at the statment that does
> something unusual, and then need to realize that it is qualified with a
> statement modifier that says "this is only for rare case".
I mostly agree, and I frequently consider[ed] exactly those points.
However, there are 2 things that played a role in my decision:
* For most conditional cases, I personally
loathe curly braces around one statement.
* The flow is actually:
do this;
do that;
DIE "whisper some curses with the last breath"
UNLESS some condition that holds mostly true;
do some other thing;
The "die" and thoughtful spacing should be pretty good clues.
However, the "unless" can be strange to think with (at first);
I figured Perlers would be happy with it.
In any case, I also like:
condition and/or (do something);
or:
condition and/or do something;
The only thing keeping me from using that more often is that I assume
other people would be less comfortable with it and that it may
introduce an unnecessary comparison of the return value of "do
something"; also, it might make the line a little long, which some
people get really angry about.
> Written without statement modifier:
>
> do this;
> do that;
> if (some consition that rarely holds true) {
> do something unusual
> }
> do some other thing;
I just have a hard time stomaching those curly braces. I really wish
perl didn't enforce them when there's only one statement. Also, I
would use some whitespace:
do this;
do that;
if (some consition that rarely holds true) {
do something unusual
}
do some other thing;
>> + $smtp->mail($raw_from) and
>> + $smtp->to(@recipients) and
>> + $smtp->data and
>> + $smtp->datasend("$header\n$message") and
>> + $smtp->dataend or
>> +
>> + die "Failed to send '$subject': " . $smtp->message . "\n";
>
> These do make things more pleasant to read.
Thanks!
P.S.
Sorry if the formatting of this email is bad; I'm in the middle of a
large move between systems, and currently I'm stuck with gmail's
webmail, which insists on reformatting my text and refusing to render
in fixed-width font (though I bet I could hack firefox's css to get
that one working.... hmmm.....), and firefox doesn't make it easy to
input tabs.
So, I've actually been writing and sending some emails with a combination of:
* vim
* date +'%a, %e %b %Y %T %z'
* uuidgen (though I've found gmail makes a Message-ID for me)
* cat path/to/email.txt | perl -pe 's/\n/\r\n/; END {print
"\r\n"}' | msmtp -t
This email was written in the webmail in firefox; I actually counted
spaces for indentation in the hope that things line up. ;-)
next prev parent reply other threads:[~2009-04-20 5:40 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-18 17:01 [PATCH RFC3.5 00/12] Introduction to Decreasing send-email Entropy Michael Witten
2009-04-18 17:01 ` [PATCH RFC3.5 01/12] send-email: Cleanup the usage text and docs a bit Michael Witten
2009-04-18 17:01 ` [PATCH RFC3.5 02/12] send-email: No longer repeatedly test if $smtp_server is a command Michael Witten
2009-04-18 17:01 ` [PATCH RFC3.5 03/12] send-email: Interpret --smtp-server "" as "use a default" Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 04/12] send-email: Verification for --smtp-server and --smpt-server-port Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 05/12] send-email: Improve redability and error-handling in send_message's sendmail code Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 07/12] send-email: Cleanup send_message 'log' code Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 08/12] send-email: Move Subject sanitization from --compose code to send_message Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 09/12] Docs: send-email: Reorganize the CONFIGURATION section Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 10/12] Docs: Embolden the CONFIGURATION references Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 11/12] Docs: send-email: Clarification of sendemail.<identity> Michael Witten
2009-04-18 17:02 ` [PATCH RFC3.5 12/12] Docs: send-email: git send-email -> 'send-email' Michael Witten
2009-04-19 1:54 ` [PATCH RFC3.5 08/12] send-email: Move Subject sanitization from --compose code to send_message Jay Soffian
2009-04-19 2:37 ` Michael Witten
2009-04-19 14:13 ` Jay Soffian
2009-04-19 14:39 ` Michael Witten
2009-04-19 14:53 ` Michael Witten
2009-04-19 16:43 ` [PATCH RFC3.5.1 08/12] send-email: Simplify --compose subject sanitation Michael Witten
2009-04-21 2:34 ` Jeff King
2009-04-21 3:29 ` Michael Witten
2009-04-20 1:42 ` [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message Junio C Hamano
2009-04-20 5:38 ` Michael Witten [this message]
2009-04-20 6:43 ` Junio C Hamano
2009-04-19 1:51 ` [PATCH RFC3.5 05/12] send-email: Improve redability and error-handling in send_message's sendmail code Jay Soffian
2009-04-19 2:13 ` Michael Witten
2009-04-19 2:17 ` Thomas Adam
2009-04-19 2:43 ` Michael Witten
2009-04-19 4:44 ` Junio C Hamano
2009-04-19 13:49 ` [PATCH RFC3.5.1 05/12] send-email: Improve readability " Michael Witten
2009-04-19 14:16 ` [PATCH RFC3.5 05/12] send-email: Improve redability " Jay Soffian
2009-04-20 1:38 ` Junio C Hamano
2009-04-20 1:58 ` Junio C Hamano
2009-04-21 2:00 ` Jeff King
2009-04-21 3:14 ` Jeff King
2009-04-19 14:19 ` [PATCH RFC3.5.1 04/12] send-email: Verification for --smtp-server and --smpt-server-port Michael Witten
2009-04-20 15:53 ` Michael Witten
2009-04-20 1:42 ` [PATCH RFC3.5 " Junio C Hamano
2009-04-20 2:38 ` Junio C Hamano
2009-04-20 3:49 ` [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message Michael Witten
2009-04-20 3:49 ` [PATCH RFC3.5 04/12] send-email: Verification for --smtp-server and --smpt-server-port Michael Witten
2009-04-18 23:35 ` [PATCH RFC3.5 03/12] send-email: Interpret --smtp-server "" as "use a default" Wesley J. Landaker
2009-04-19 0:13 ` Michael Witten
2009-04-19 14:16 ` [PATCH RFC3.5.1 " Michael Witten
2009-04-20 1:41 ` [PATCH RFC3.5 " Junio C Hamano
2009-04-20 2:52 ` Michael Witten
2009-04-20 1:41 ` [PATCH RFC3.5 02/12] send-email: No longer repeatedly test if $smtp_server is a command Junio C Hamano
2009-04-20 2:37 ` Michael Witten
2009-04-20 4:21 ` Junio C Hamano
2009-04-20 4:53 ` Subject: " Michael Witten
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=b4087cc50904192238j744f353dtf5f6a616cada8cd8@mail.gmail.com \
--to=mfwitten@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).