Untitled.Bat |
Developer, dad & dangerously dopey.....Also awesome at alliteration and assonance . Visit my main website @ http://www.xerxesb.com if you're tech-inclined |
To write clean code, you must first write dirty code and then clean it. Writing clean compositions is a matter of successive refinement.
When you recognise that code is becoming dirty, and that further changes and extension to the code will make it even dirtier, STOP. It’s time to refactor your implementation.
Start small and use small, successive increments to improve (refactor) the code. Using TDD and a unit-testing framework will give you confidence to make changes to your code. Putting code in so you can later take i our again is pretty common in refactoring. Refactoring is a lot like solving a Rubik’s cube - there are lots of little steps to achieve a large goal.
“It is not enough to code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don’t have enough time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down. Time and time again I have seen teams grind to a crawl because, in their haste, they created a malignant morass of code that forever thereafter dominated their destiny.” - Bob Martin
Clean Code: Chapter 14