TECHARRAZ

1. Name ::

A variable name reflects it’s presence and usage in a program. A variable name thus should be concise, understandable, definitely memorable and if possible pronounceable.
Global :- Use descriptive names for global variables as they can crop up anywhere in a code. Another good method is to include a comment with each global variable. Also begin global variable with a capital letter.
Pointers :- p and q are conventional, or end variable name with p.
Strings :-s and t are conventional, or use a “str” prefix.
Loops :-i and j are conventional.
Constants :- Constants are always in uppercase.
With this convention, it becomeseasy to read codes.
With all this, let the name convey some information and do not give in to long names. In short, avoid bstraction as well as extra information.

2.Statements ::
Indent your statements and code blocks. They improve readibility. A teacher at our college refuses to look at the code if it is not indented! If a statement looks ambiguous, parenthesize it. Use statements in their natural form. Complicated logic is no achievement. Be clear. The most concise code is not always the most appreciated one.

3.Obsolete styles ::
Eg. Function Macros.
There is a tendency among older C programmers to write macros instead of functions for very short computations that will be executed frequently. Operations such as getchar() and character tests like isdigit() are officially sanctioned examples. The reason was performance: a macro avoids the overhead of a function call. So, the call stack is not accessed unnecessarily. This argument was weak even when C was first defined, a time of slow machines and expensive function calls; so, today it is irrelevant. With modern machines and compilers, the drawbacks of function macros outweigh their benefits. Avoid function macros. In C++, inline functions render function macros unnecessary; in Java, there are no macros. In C, they cause more problems than they solve.
Eg.

-In this code, the parameter c appears twice.Thus if we use it with a code like: isupper(c=getchar()), the value of c will be read, passed to the first check, ie; c<=’A’ and then a new value will be awaited by the runtime. This is a minor prolem, but a troublesome bug!

4.Comments ::
Use comments to make the code understandable, not overload it with tpographic details. Dont’ let comments become clutters. Do not comment to cover up mistakes or justify bad codes. Do not comment to confuse and lastly do not ever contradict your code in comments.

And lastly, good style is a matre of practice. With pracctice, the subconcious tells us what to type in and in what way.
Happy coding…..

No Responses to “Trends to good coding style”

No comments yet

Leave a Reply