From: William Morgan Date: Mon, 14 Jan 2008 00:50:40 +0000 (-0800) Subject: HACKING update: and/or versus ||/&& X-Git-Url: https://git.notmuchmail.org/git?a=commitdiff_plain;h=6421200176dd8f27815e1d37ce10448d4f24d41f;p=sup HACKING update: and/or versus ||/&& --- diff --git a/HACKING b/HACKING index bc85c4a..04c2517 100644 --- a/HACKING +++ b/HACKING @@ -20,9 +20,8 @@ the installed gem before submitting any bug reports. Coding standards ---------------- -- Don't wrap code unless it really benefits from it. The days of 80-column - displays are long over. But do wrap comments and other text at whatever vi - gq does. +- Don't wrap code unless it really benefits from it. +- Do wrap comments at 72 characters. - Old lisp-style comment differentiations: # one for comments on the same line as a line of code ## two for comments on their own line, except: @@ -32,7 +31,12 @@ Coding standards - The one exception to poetry mode is if-statements that have an assignment in the condition. To make it clear this is not a comparison, surround the condition by parentheses. E.g.: - - if a == b BUT if(a = some.computation) - ... ... something with a - end end + if a == b if(a = some.computation) + ... BUT ... something with a + end end +- and/or versus ||/&&. In Ruby, "and" and "or" bind very loosely---even + more loosely than function application. This makes them ideal for + end-of-line short-circuit control in poetry mode. So, use || and && + for ordinary logical comparisons, and "and" and "or" for end-of-line + flow control. E.g.: + x = a || b or raise "neither is true"