C has been the most widely language and liked by a billion of programmers all around the world. It is its simplicity along with the strength and capabilities that made it so popular. I m no exception. I like C-Programming as much as I like sweets or anything else.
For the interested ones I have got some valuable stuff.
A Question Paper on C Prepared by myself
So get ready, C-Programmers! For a brain storming exercise on C. This paper was designed by me for C-Debugging Contest-2001 organised by Computer Science Students' Council(COSSCO), B. I. E. T., Jhansi
Other Brain-Storming Exercises for C-Programmers
C-Debugging 2000 @COSSCO I got first position in this
Tips to improve C-Programming
This article will definitely help everybody to improve C-Programming skills. The article was published in the monthly magazine of COSSCO, BIET Jhansi during session 2000-01.
During the past few years a great deal of attention has been focused on coding style. The goal of good coding style is to provide easily understood, straightforward, and elegant. Consistent coding style among different programmers enhances perfect communication and eases debugging, testing and modification of source code.
There is no single set of rules that are applied in every situation: however, there are general guidelines that are widely applicable. A number of these guidelines for coding in ‘C’ are listed below:
1. Don’t use global / static variables unless they are exclusively needed. Rather rely on passing information between functions. Try to hide data structures behind functions.
2. Declare one name (Identifier) per declaration line.
3. Keep common and local names short and uncommon and non-local names longer(but not too long).
4. Avoid similar looking names.
5. Maintain a consistent naming style(like using all uppercase for macros etc.).
6. Use explicit type in declaration. Don’t rely on default int .
7. Avoid unnecessary assumptions about the size and range of the types, if possible.
8. Prefer plain int over short, long or unsigned int.
9. Prefer plain char over signed or unsigned char.
10. Avoid unsigned arithmetic.
11. View type conversions, especially floating point to integer, with suspicion.
12. Don’t use explicit or implicit conversions to a smaller type e.g. int to char.
13. Avoid nontrivial pointer arithmetic.
14. Take care not to write beyond the array.
15. Before using a pointer make sure that it contains a valid / initialized address.
16. Avoid void * except in low-level code.
17. Avoid complicated expressions. If in doubt about operator precedence, parenthesize.
18. Avoid goto.
19. Avoid do statements.
20. Keep comments crisp.
21. Maintain a consistent indentation style. *
22. Avoid macros.
23. Don’t return pointers to local variables. If it is exclusively needed use dynamic memory allocation explicitly using malloc( ) and free( ). But always be cautious when returning objects allocated dynamically.
24. Don’t be too clever. e.g.
prefer if (a!=0){ ……..} over if(a){ …………. }.
25. Don’t nest too deeply.
26. Use pointer arguments to functions only when the function modifies the values or the variables are too big in size(but always be cautious!).
Coding standards are specifications for a preferred coding style. Coding standards are often viewed by programmers as mechanism to constrain and devalue the programmer’s creative problem solving skills. This argument is usually advanced by the programmers who do not understand the spirit or intent of good coding style. Without a framework of standards to guide and channel an activity, creativity becomes meaningless chaos. Thus it is desirable that all programmers on a software project adopt a similar coding style so that all programmers must think alike or that they must slavishly implement all algorithms in exactly same manner.
Several conditions are necessary to obtain voluntary adherence to programming guidelines. First, programmers must understand the value of programming guidelines and coding style. Second, programmers must have opportunity to participate in establishing guidelines. Third, the guidelines must be subjected to review and revision when they become burdensome. Fourth, there must be mechanism for allowing violations of guidelines in special circumstances.
