More on this book
Community
Kindle Notes & Highlights
you already know that spending time keeping your code clean is not just cost effective; it’s a matter of professional survival.
But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.
Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule.
It’s your job to defend the code with equal passion.
So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.
Some of us are born with it. Some of us have to fight to acquire it. Not
They used the metaphor of broken windows.
are our school of thought
The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.
In general output arguments should be avoided. If your function must change the state of something, have it change the state of its owning object.
it is not an excuse to leave bad code in the system.
The functionality that you create today has a good chance of changing in the next release, but the readability of your code will have a profound effect on all the changes that will ever be made. The coding style and readability set precedents that continue to affect maintainability and extensibility long after the original code has been changed beyond recognition. Your style and discipline survives, even though your code does not.
Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.
postpone decisions until the last possible moment.
Writing tests leads to better designs.
