You don’t speak in code, but you can make the code speak to others.
When you write software, you should view it as a form of communication. The message you are trying to send is a declaration of intent to the next programmer who has to read your code. The logical arrangement of methods and symbols will instruct the system on how to perform a routine. The naming of methods and objects is where you communicate to others what the intended result should be.
Write in English, not in code. As best as you can, you should use plain words to describe what is going on. Do not abbreviate when it is not necessary. Always make the intent clear and distinct. It should be obvious at a glance what method intends to do and which objects it is working on.
Avoid using technical language. Instead, use words from the business domain. Also, avoid vague terms like “status,” “type,” and “flag.” If a customer_account object has three attributes named status, type, and flag, then it is uncertain how a developer should use each of these attributes.
The easier it is to read and understand code, the better. It will be less likely that there will be misunderstandings that lead to defects. As we all care deeply about code quality, we should try to make this job easy on ourselves.
Today's Card 