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