Common Programming Habits

blog

Be a better programmer


Study your source control process
forever-alone-meme-generator-want-to-watch-source-code-nobody-wants-to-go-with-you-1f91ec[1]You know that thing users like to do, where they pick up your application for the first time and get angry because it doesn’t do things exactly the way they want and then they refuse to learn how the program works? You’re left scratching your head wondering why they didn’t bother to learn the 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 source control 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 by making your source control repository look like the ugly mess you are used to creating on your local hard drive defeats the purpose. You might as well just have good backups of your local system and call it a day.


Use obvious variable naming
38574318[1]This one comes up all the time: developers just give variables uninformative names and think it doesn’t matter. Well, it does matter any time someone else comes in to look at the code. I can’t speak 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 it for you) will make a measurable difference in productivity. Stop making excuses and use better variable names.


Assume the worst from your peers
i-cant-read[1]I’d love to think that everyone I worked with was as good, if not better than me at writing software. In some jobs, it has been usually true; but in others, it wasn’t. I did learn, though, that you have to write your code as if someone with six months of experience (or someone with lots of experience who just is not very good) is going to be working on it next, because it may very well be 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. I’ve discovered that writing code is like cooking: To please everyone, you can’t go for the escargot or 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.


Assume the worst from your users
frabz-TRAINING-SESSION-ON-TUESDAY-AWW-HELL-NO-5a816b[1]
There is a bell curve of tech savvy with our users. We tend to miss the mark on usability and hit the lower end of the bell, but that still leaves about 10% to 20% of users in the dark. Aiming for the lowest common denominator means just that. With a few exceptions, you have to assume that the person using your application will never look at documentation, attend training, or otherwise seek out how to use your application.


Document the reason for a change
6ej0zr[1]All too often, there will be a change in an application but no documentation of why the change was made. A few months later, someone will notice that the change conflicts with another requirement and demand to know why it was made, and no one will actually know. The next thing you know, everyone will be losing a lot of time trying to figure out where the change came from and why. By documenting the purpose of the change (and who the requester is), you’ll be saving everyone a big headache down the road.


Explain the purpose of algorithms
math-reaction_o_258488[1]
In the same vein, any algorithm should have a clear explanation of why it was chosen. For example, I support a CRM system that has a nonintuitive formula for applying discounts to purchase. No one can quite explain why this specific formula is in place, but it is not working in some scenarios. We are not quite sure how to change it, because the reason for its current form is unknown. All it would have taken was a simple comment that said, “We do it like this because of consideration CYZ,” and everything would be fine.


Provide contextual help
512a9527b4731b21157a1b969142eaa191729173ea08770941e5530f5c770ce9[1]We all know that users tend to gloss over training materials. At the same time, it’s important to provide a variety of contextually available help in your application. While users won’t read the manual, they are likely to click the giant question mark next to the input control they don’t understand. Put your help access as close to the UI controls as possible with targeted text to make it easy for users to get the help they need. Also, remember to use terms and phrases your users will understand, not internal jargon.


Perform cross-platform testing
3v71yg[1]If you are writing Web applications, it is important to test them on a variety of platforms. You will want to check different browsers on different platforms. Sounds like a hassle, right? It is. Luckily, there are some tools to help with that.


Keep the users in mind
MTIyMjkzNjY5NjIwNjQxMDQ5[1]A lot of business requirements don’t help the users at all, and some may even annoy them. These requirements may be non-functional, but are designed to satisfy someone in the marketing or sales departments. A great example is a registration page that asks for a lot more information (and makes 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 –while overestimating users’ desire to get the benefits of registration. Remember that there are few unique propositions in this industry, and you do not have the luxury of turning users away. Fight on behalf of your users to make the best application possible.




Reference: Techrepublic.com