Code quality guide: Difference between revisions
From LimeSurvey Manual
| Line 27: | Line 27: | ||
Some code are "hot spots" - changed often. Those parts should require higher quality than other code. | Some code are "hot spots" - changed often. Those parts should require higher quality than other code. | ||
== Classes == | |||
todo | |||
== Functions == | == Functions == | ||
todo | |||
== Documentation == | |||
todo | |||
== OOP design == | |||
todo | |||
== The PHP of yesterday == | |||
Old idioms and habits that should be abandoned. | |||
== Security == | |||
todo | |||
== Performance == | |||
todo | |||
== Static analysis == | |||
todo | |||
Revision as of 21:13, 2 April 2021
DRAFT
Prologue
- 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 and understand). You have to find a balance that is adapted to the current situation and risk analysis, in which code quality becomes a risk mitigation technique.
- 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, in the same way you are now reading code by developers that no longer work with us.
- 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.
- 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.
- It's easy to forget cross-cutting concerns like translation and security. Keep a mental note.
- Stress affects code quality. 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 be measured?
Quality attributes related to code quality:
- Readability
- Testability
- Maintainability
- Performance
- Security
It's better to avoid emotional language when describing code quality, like "clean" or "dirty". Be precise.
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, say, functional or hardware-close programming.
Some code are "hot spots" - changed often. Those parts should require higher quality than other code.
Classes
todo
Functions
todo
Documentation
todo
OOP design
todo
The PHP of yesterday
Old idioms and habits that should be abandoned.
Security
todo
Performance
todo
Static analysis
todo