10 good programming habits


Published on

Book learning will take you only so far. In the trenches, you need to develop sensible, effective habits like these.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

10 good programming habits

  1. 1. 10 Good Programming HabitsTakeaway: Book learning will take you only so far. In the trenches, you need to develop sensible,effective habits like these.You learn lots of things when you go to college and get a computer science degree or read a how-to-program book. Unfortunately, a number of good programming habits are either untaught or takea good amount of practice to turn into a way of life. Here are 10 such habits you should cultivateto become a better programmer.1: Learn your source control processYou know that thing users like to do, where they pick up your application for the first time and getangry because it doesn’t do things exactly the way they want — and then they refuse to learn howthe program works? You’re left scratching your head wondering why they didn’t bother to learnthe application, which would have saved them all sorts of problems.Well, a lot of developers do that too, when it comes to working with source control. Every sourcecontrol system is a bit different and has a workflow that maximizes the value you get from it.Learn that workflow! It may take some time, research, and practice, but trying to fight it bymaking your source control repository look like the ugly mess you are used to creating on yourlocal hard drive defeats the purpose. You might as well just have good backups for your localsystem and call it a day.2: Go with obvious variable namingThis one comes up all the time: developers just give variables uninformative names and think itdoesn’t matter. Well, it does matter any time someone else comes in to look at the code. I can’tspeak for all developers, but I have yet to meet one who is typing for eight hours a day straight.Adding a few keystrokes for better variable names (especially when modern IDEs will autofill itfor you) will make a measurable different in productivity. Stop making excuses and use bettervariable names.3: Use interfaces, not classes when possibleI violate this one all the time, and I know it. Whenever possible, code to an interface instead of aclass. For example, if your class needs to return an enumeration of Integers, there’s no need toreturn a List<int>; return an IEnumerable<int>. This allows recipients to do what they wantwithout needing to recast or transform the results into a class that meets their needs.4: Assume the worst from your peersI’d love to think that everyone I worked with was as good, if not better than me at writingsoftware. In some jobs, it was usually true; but in others, it wasn’t. I did learn, though, that youhave to write your code as if someone with six months of experience (or someone with lots ofexperience who just is not very good) is going to be working on it next, because it may very wellbe true. What that means is that you can’t afford to write “fancy” or excessively “elegant” code.The next person to look at it could end up making a mess because he or she doesn’t understand it.
  2. 2. I’ve discovered that writing code is like cooking: To please everyone, you can’t go for the escargotor liver pate; you need to be serving steak and potatoes. Keep your code basic and straightforward,and those coming behind you to maintain it will be able to do their job.5: Assume the worst from your usersThere is a bell curve of tech savvy with our users. We tend to miss the mark on usability and hitthe lower end of the bell, but that still leaves about 10% - 20% of users in the dark. Aiming for thelowest common denominator means just that. With a few exceptions, you have to assume that theperson using your application will never look at documentation, attend training, or otherwise seekout how to use your application.6: Document the reason for a changeAll too often, there will be a change in an application but no documentation of why the changewas made. A few months later, someone will notice that the change conflicts with anotherrequirement and demand to know why it was made, and no one will actually know. The next thingyou know, everyone will be losing a lot of time trying to figure out where the change came fromand why. By documenting the purpose of the change (and who the requester is), you’ll be savingeveryone a big headache down the road.7: Explain the purpose of algorithmsIn the same vein, any algorithm should have a clear explanation of why it was chosen. Forexample, I support a CRM system that has a nonintuitive formula for applying discounts topurchases. No one can quite explain why this specific formula is in place, but it is not working insome scenarios. We are not quite sure how to change it, because the reason for its current form isunknown. All it would have taken was a simple comment that said, “We do it like this because ofconsideration CYZ,” and everything would be fine.8: Provide contextual helpWe all know that users tend to gloss over training materials. At the same time, it’s important toprovide a variety of contextually available help in your application. While users won’t read themanual, they are likely to click the giant question mark next to the input control they don’tunderstand. Put your help access as close to the UI controls as possible with targeted text to makeit easy for users to get the help they need. Also, remember to use terms and phrases your users willunderstand, not internal jargon.9: Perform cross-platform testingIf you are writing Web applications, it is important to test them on a variety of platforms. You willwant to check different browsers on different platforms. Sounds like a hassle, right? It is. Luckily,there are some tools to help with that. Check out the offerings from Sauce Labs to make it a biteasier to cross-platform test your Web applications.10: Keep the users in mindA lot of business requirements don’t help the users at all, and some may even annoy them. Theserequirements may be non-functional but are designed to satisfy someone in the marketing or sales
  3. 3. departments. A great example is a registration page that asks for a lot more information (andmakes it mandatory) than most users feel comfortable giving. While I understand the motivation(making their jobs easier), developers often underestimate how much users dislike it –whileoverestimating users’ desire to get the benefits of registration. Remember that there are few uniquepropositions in this industry, and you do not have the luxury of turning users away. Fight on behalfof your users to make the best application possible.What would you add?What other good practices do you think are underused? Do you have any pet peeves you’d add tothis list?Recommend Office .NET Component:Spire.XLS for .NETSpire.Office for .NETSpire.Doc for .NETSpire.PDF for .NETSpire.DataExport for .NET