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 ec33170f691..47bb2813d68 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>
--
GitLab