Leave the campground cleaner than you found it. is a mini series on writing maintainable code without pulling your hair out. Click here for , , & . OOT Object Oriented trick #1 trick #2 trick #3 trick #4 Entropy : lack of order or predictability; gradual decline into disorder. /ˈɛntrəpi/ Entropy in physics refers to the amount of “disorder” in a system. The laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum. While the laws of physics don’t apply to software, entropy hits it hard. When disorder increases in software, programmers call it “software rot.” The Broken Window Theory Software rot starts with . one broken window One broken window, if left unrepaired for a substantial amount of time, instils a sense of abandonment. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality. The Boy Scout Rule There are times when I have hacked together code because the entire component was somewhat hack-y. This only made the code worse than what it already was and made it tremendously difficult to change it later. In contrast, if you are working on a team/project where the code is cleanly written, well designed, and elegant — you will likely take extra care not to mess it up. Don’t leave “broken windows” unrepaired. Fix each one as soon as it is discovered. Leave the code cleaner than you found it. Dealing With Entropy As Uncle Bob says, it’s not enough to write code well, the code has to be over time. If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement. kept clean Done And Gets Things Smart Programmers are all smart and get things done but we should cultivate the habit of getting things done and making code smart. “You want someone who, when you give them a project to research, will come in on Monday and say: “I’m , and by the way I improved the existing infrastructure while I was at it.” — Done Stevey’s Blog Rants TL;DR You see evil and you destroy it. Always be refactoring. I’ve found that the following prioritization helps quite a lot: bugs > refactoring > features This applies to any programming paradigm, not just OOP. Andy Hunt and Dave Thomas have written about this extensively in their book . The Pragmatic Programmer Be sure to check it out and tell me your views: Twitter Check out trick #6 . here If you liked this post, please hit the little heart! ❤
