git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael Witten <mfwitten@gmail.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: Sun, 19 Apr 2009 18:42:43 -0700	[thread overview]
Message-ID: <7vskk4nlrg.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 1240074128-16132-7-git-send-email-mfwitten@gmail.com

Michael Witten <mfwitten@gmail.com> writes:

> +				die "Server does not support STARTTLS: " . $smtp->message . "\n"
> +					unless $smtp->code == 220;

Statement modifiers merely make things even less readable, especially when
the conditional is the unlikely case.  Please do not add more of them.

	do this;
	do that;
	do something
        	if some condition that holds true most of the time;
	do some other thing;

is already hard to follow, but it is probably excusable in some cases,
because your thought can flow "ah, Ok, these four things are done in
sequence" when you are quickly scanning the code to understand the overall
structure, letting your eyes ignore the "true most of the time" part.

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".

Written without statement modifier:

	do this;
	do that;
	if (some consition that rarely holds true) {
		do something unusual
        }
	do some other thing;

it is much easier to coast over; you can tell "Ah, after doing this and
that, in the normal case we do some other thing" and do not have to even
look at the details of "something unusual" part.

> -		$smtp->mail( $raw_from ) or die $smtp->message;
> -		$smtp->to( @recipients ) or die $smtp->message;
> -		$smtp->data or die $smtp->message;
> -		$smtp->datasend("$header\n$message") or die $smtp->message;
> -		$smtp->dataend() or die $smtp->message;
> -		$smtp->code =~ /250|200/ or die "Failed to send $subject\n".$smtp->message;
> +		SEND_MAIL:
> +
> +		$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.

  parent reply	other threads:[~2009-04-20  1:44 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             ` Junio C Hamano [this message]
2009-04-20  5:38               ` [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message Michael Witten
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=7vskk4nlrg.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mfwitten@gmail.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).