Thursday, November 26, 2009

Coding Rules

There are many rules when it comes to coding.  Some can only be bent (they get broken and bugs magically appear); the rest can be broken. The question is which rules are ones you can break, and which can you bend?  Here are some of my thoughts....

Firstly, try to make your code readable.  It might take a bit of getting used to, but try to write code in functions where each function is 10-15 lines long.  There might be a trail to follow to debug the code, but it is better than trying to untangle a mess of one big function that does everything.  It can, when you think about it, also lead to more reusable code.

Know what the function of the code is to be before you start. This is one that can be broken. Whilst we as coders can't know the in's and out's of everything, we do understand functionallity. So, before you start, understand the inputs to what your writing, how it should be processed, and the outputs.  Then take a step back and think about that you need to do. When I do that, it helps me to focus more on what I need to do, and usually means that I only have to do it once.  A trap is to get an outline and start coding without thinking about what you need the code to do.

Finally, be teachable.  In any code that I write, I try to always be of the mind that there is a better way to do it.  It dosent mean that I am always rewriting my code and so get nothing done, but it means that when someone has an idea as to a different way of doing something, I do my best to look at what they are saying objectivily.  Sometimes I am the one who is right, sometimes not.  Many a time fellow coders, and even on the odd occaision non-coders, have suggested changes to my code that would make the code faster, easier to understand or just neater.

Anyways, these are just a few of my thoughts on the rules of coding.  If you have any others let me know, this isn't ment to be a definative list, just some of my thoughts on coding rules.

No comments:

Post a Comment