Pages

December 3, 2013

Whats the buzzword 'programming best-practices' all about?

This post is about what does the programming best practices buzz word means, and not a actual list of the best practices(which will surely differ language to language and scenario to scenario, but the core best-practices would be the same, few of which discussed here).

It's kind of hard to think the usefull-ness of this buzz-word when it is taught(ok not actually taught ;)) in collage. You need to work on some actual project, mission critical app, or any software that deals with money ;), to understand it in real sense. Until then it's just another `yea-i-know-it-well` kind of word in your head.

Let's just discuss few of them to get a better picture -
  • Commenting your code
  • Better logging
  • Configurable

Commenting your code
You'll come across two paradigms going through tutorials or following some great programmers ( hackers as ycombinator guys say )

 - Always Comment your code
 - Good program doesn't need comments, it should be self-explanatory

My feeling is both are extremes comments on how to comment (theres' recursion again :)). You should have atleast a single descriptive comment for each method. And if a method does something complex, you should have comments at proper places. This is just not for the people who have to maintain your code once you move on, but it's for yourself. If you come back to your own code after few months, you'll find it difficult to parse it in your head, if it didn't had comments.

Better logging
This refers to the messages/sysouts/println you log into the log files. You should log minimum self-exhaustive details in the logs, to narrow down the problem.
The level of information that is logged should be changeable at run time. And hence, you'll find a lot of libraries written for each language, each framework to accomplish this. Restarting the application when config change doesn't come under this category. You should be able to change it on the fly.

Configurable
Your application refers to many external entities. Interacts with user in the front-end and talks to the database at the back-end. There can be lot of customization that refers to the domain of your application ( what programmers in the financial world would say as 'business logic' ), and this shouldn't
never ever be hard-coded in the code.
Have it configured to be read from a ini file or properties of xml or command-line would save you a lot of effort and time. And in many cases head-ache.

No comments:

Post a Comment