From 4720ad515ed28f5f93b6702c1a7fc6e0978944c1 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 10 Jul 2010 18:37:00 +0000
Subject: [PATCH] Add a note about preferred window width to the section about
 code formatting conventions.

---
 doc/src/sgml/sources.sgml | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
index ec33170f69..47bb2813d6 100644
--- a/doc/src/sgml/sources.sgml
+++ b/doc/src/sgml/sources.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.36 2010/06/28 17:48:26 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.37 2010/07/10 18:37:00 tgl Exp $ -->
 
  <chapter id="source">
   <title>PostgreSQL Coding Conventions</title>
@@ -18,6 +18,13 @@
     <literal>while</>, <literal>switch</>, etc go on their own lines.
    </para>
 
+   <para>
+    Limit line lengths so that the code is readable in an 80-column window.
+    (This doesn't mean that you must never go past 80 columns.  For instance,
+    breaking a long error message string in arbitrary places just to keep the
+    code within 80 columns is probably not a net gain in readability.)
+   </para>
+
    <para>
     Do not use C++ style comments (<literal>//</> comments).  Strict ANSI C
     compilers do not accept them.  For the same reason, do not use C++
@@ -50,6 +57,8 @@
     rules, it's a good idea to do so.  Your code will get run through
     <application>pgindent</> before the next release, so there's no point in
     making it look nice under some other set of formatting conventions.
+    A good rule of thumb for patches is <quote>make the new code look like
+    the existing code around it</>.
    </para>
 
    <para>
-- 
2.40.0