The PEAR Coding Standards apply to code that is part of the official PEAR distribution. Coding standards often abbreviated as CS among developers and they aim to keep code consistent to be easily readable and maintainable by most of PEAR folks.

The original coding standards have been adjusted several times through RFCs:

Those RFCs have been integrated into this document.

The PEAR2 Coding Standards define several other rules that have to be followed once PEAR2 is in place.

Coding Standards (Previous) Indenting and Line Length (Next)
Last updated: Sat, 16 Feb 2019 — Download Documentation
Do you think that something on this page is wrong? Please file a bug report.
View this page in:
  • English

User Notes:

Note by: hm2k
Redirected here from the "Add Patch" page with the statement "Make sure your coding style complies with Coding Standards".

I don't see the term "patch" on that page, which specific section should I be looking at?

However, I managed to locate the instructions for submitting a patch here:

Unfortunately I see no Windows support WinMerge or TortoiseSVN.
Note by: Jim
Rules, rules and more rules. I can understand the length. Tabs, on the other hand, pl--ease - I like to see the code without scrolling or wrapping. As long as the tabs are noticeable and well placed, two spaces per tab is ideal = easily read.
Note by:
From the PEP 8 -- Style Guide for Python Code about maximum line length:

"Limit all lines to a maximum of 79 characters.

There are still many devices around that are limited to 80 character
lines; plus, limiting windows to 80 characters makes it possible to have
several windows side-by-side. The default wrapping on such devices
disrupts the visual structure of the code, making it more difficult to
understand. Therefore, please limit all lines to a maximum of 79
characters. For flowing long blocks of text (docstrings or comments),
limiting the length to 72 characters is recommended."

IMHO, it's a good choice.
Note by: akronymn
The suggestion on line lengths is only partly due to terminal considerations. Readability of code is also a very important issue. It's not about setting a precise limit for the sake of consistency so much as giving a guideline to make sure that your code is easily readable both by yourself and others who must follow it later.
Note by: SnowDrummer
That's a silly note to add. 75-85 is ~80 characters for that very reason (standard terminal width). If you only go a couple characters over there is no reason to split your code into two lines.
Note by:
If you're limiting 75-85 chars, why not just limit to 80 chars ? There's no point pissing off the people that still respect the most common terminal width.