Приглашаем посетить
Отели (hotels.otpusk-info.ru)

Chapter 1.  Coding Styles

Previous
Table of Contents
Next

1. Coding Styles

"Everything should be made as simple as possible, but not one bit simpler."

Albert Einstein (18791955)

"Seek simplicity, and distrust it."

Alfred North Whitehead (18611947)

NO MATTER WHAT YOUR PROFICIENCY LEVEL in PHP, no matter how familiar you are with the language internals or the idiosyncrasies of various functions or syntaxes, it is easy to write sloppy or obfuscated code. Hard-to-read code is difficult to maintain and debug. Poor coding style connotes a lack of professionalism.

If you were to stay at a job the rest of your life and no one else had to maintain your code, it would still not be acceptable to write poorly structured code. Troubleshooting and augmenting libraries that I wrote two or three years ago is difficult, even when the style is clean. When I stray into code that I authored in poor style, it often takes as long to figure out the logic as it would to have just re-implemented the library from scratch.

To complicate matters, none of us code in a vacuum. Our code needs to be maintained by our current and future peers. The union of two styles that are independently readable can be as unreadable and unmaintainable as if there were no style guide at all. Therefore, it is important not only that we use a style that is readable, but that we use a style that is consistent across all the developers working together.

I once inherited a code base of some 200,000 lines, developed by three teams of developers. When we were lucky, a single include would at least be internally consistentbut often a file would manifest three different styles scattered throughout.


Previous
Table of Contents
Next