# HG changeset patch
# User Rob Landley <rob@landley.net>
# Date 1402160634 18000
# Node ID 97c7f42068b50b37185e874a4a32fe2442eb16a8
# Parent  d90f692a50d4bc919e3f67b19092b91a6e5ca111
Minor tweaks to code style section.

diff -r d90f692a50d4 -r 97c7f42068b5 www/design.html
--- a/www/design.html	Sat Jun 07 10:42:20 2014 -0500
+++ b/www/design.html	Sat Jun 07 12:03:54 2014 -0500
@@ -372,15 +372,17 @@
 <p>When there's a shorter way to say something, we tend to do that for
 consistency. For example, we tend to say "*blah" instead of "blah[0]" unless
 we're referring to more than one element of blah. Similarly, NULL is
-really just 0 (and C will automatically typecast 0 to anything),
-"if (function() != NULL)" is the same as "if (function())",
-"x = (blah == NULL);" is "x = !blah;", and so on. (The goal is to be
+really just 0 (and C will automatically typecast 0 to anything, except in
+varargs), "if (function() != NULL)" is the same as "if (function())",
+"x = (blah == NULL);" is "x = !blah;", and so on.</p>
+
+<p>The goal is to be
 concise, not cryptic: if you're worried about the code being hard to
 understand, splitting it to multiple steps on multiple lines is
 better than a NOP operation like "!= NULL". A common sign of trying to
 hard is nesting ? : three levels deep, sometimes if/else and a temporary
 variable is just plain easier to read. If you think you need a comment,
-you may be right.)</p>
+you may be right.</p>
 
 <p>Comments are nice, but don't overdo it. Comments should explain _why_,
 not how. If the code doesn't make the how part obvious, that's a problem with