Code quality guide

DRAFT

Prologue

1. Be risk aware. Too perfect code can be a business risk (slow to write, maybe over-designed). Too sloppy code can also be a business risk (hard to maintain). You have to find a balance that is adapted to the current situation and risk analysis.
2. Be humble. LimeSurvey was made by developers from all over the world, with different age, education and experience. Your code might be read by a completely different team ten years from now.
3. Performance matters sometimes, and shouldn't be disregarded completely. In particular, database queries using the ORM and ActiveRecord can be problematic. Some surveys have thousands of questions and hundreds of thousands of responses. Fast response time is also important for a fluid user experience.
4. It's harder to read code than to write code. Don't choose patterns that are easy or fast to write, but that are easy to read.
5. It's easy to forget cross-cutting concerns like translation and security. Keep a mental note.
6. Stress affects code quality greatly. If your stress level is too high to write code with proper quality, take a step back and discuss it with your boss.

Quality

What is quality? Which aspects of quality can we measured?

• Readability
• Testability
• Maintainability
• Performance
• Security

Idiomatic code is more readable than non-idiomatic code. What's idiomatic depends on which context or domain you work in. We work in PHP and web application development, and have other idioms than in functional programming.

Some code are "hot spots" - changed often. Those parts should require higher quality than other code.