Chapter 8: Errors and Habits
PART 1: ERRORS
Errors are the problems or the faults that occur in the program, which makes the behavior of the program abnormal, and experienced developers can also make these faults. Programming errors are also known as the bugs or faults, and the process of removing these bugs is known as debugging.
These errors are detected either during the time of compilation or execution. Thus, the errors must be removed from the program for the successful execution of the program.
There are mainly five types of errors in C programming:
?
Syntax error: Errors occur when you violate the rules of writing C syntax are said to be “Syntax errors”. This compiler error indicates that this must be fixed before the code will be compiled. These errors are identified by the compiler so these errors are called “compile-time errors”.
For example:
If we want to declare the variable of type integer,?
int a; // this is the correct form
Int a; // this is an incorrect form.?
Commonly occurred syntax errors are:
If we miss the parenthesis ' } ' while writing the code.
Displaying the value of a variable without its declaration.
If we miss the semicolon (;) at the end of the statement.
?
Run-time error: Errors which are occurred after a successful compilation of program is said to be “run-time errors”. Number divisible by zero, array index out of bounds, string index out of bounds, etc. are most frequent run-time errors. These errors can’t be very hard to detect at the compile time.
For example:
A)
void main()
{
int a=10;
int c=a/0;// Here number divisible zero error occurs
}
?B)
void main()
{
int a[3]={1,2,3};
int out=a[4];// Here array out of bounds error occurs
}
Linker error: Linker errors are mainly generated when the executable file of the program is not created. This can be happened either due to the wrong function prototyping or usage of the wrong header file. For example, the main.c file contains the sub() function whose declaration and definition is done in some other file such as func.c. During the compilation, the compiler finds the sub() function in func.c file, so it generates two object files, i.e., main.o and func.o. At the execution time, if the definition of sub() function is not found in the func.o file, then the linker error will be thrown. The most common linker error that occurs is that we use Main() instead of main().
For example:
void Main() // Here Main() method used instead of main() method
{ //body }
Logical error: If our expectation is one thing and result output is other thing then that kind of error we said it as “Logical errors”. Let’s suppose if we want sum of the 2 numbers but given output is the multiplication of 2 numbers then this said to be Logical error. It can be detected by line-to-line debugging.
The logical error is an error that leads to an undesired output. These errors produce the incorrect output, but they are error-free, known as logical errors. These types of mistakes are mainly done by beginners. The occurrence of these errors mainly depends upon the logical thinking of the developer. If the programmers sound logically good, then there will be fewer chances of these errors.
For example:
void Main(){
printf("%d",sum(10,20));
}
int sum(int a, int b){
return x*y;//expectation is sum but we are multiplying the numbers
}
Semantic error: Semantic errors are the errors that occurred when the statements are not understandable by the compiler.
The following can be the cases for the semantic error:
Use of a un-initialized variable:????int i; i=i+2;
Type compatibility: ??????????????????????int b = "string";
Errors in expressions????????????????????int a, b, c; a+b = c;
Array index out of bound?????????????int a[10]; a[10] = 34;
PART 2: HABITS
GOOD HABIT #1: WRITE CLEAR CODE
Writing clear code involves not only writing programs that are easy to understand, but writing programs that are easy to read. Get in the habit of using adequate spacing, blank lines and indentation.
?
GOOD HABIT #2: DEVELOP A CONSISTENT STYLE
Get in the habit of organizing your programs using a consistent scheme. Define arrays, create labels and declare length attributes at the same place in your programs and group similar statements together. This makes it easier to see what you've done and easier to modify.
?
GOOD HABIT #3: CHECK YOUR PROGRAMS ?
New programmers all too often scan the log looking only for errors. ?Just because your program has run successfully does not mean it has done what you intended for it to do. The log provides invaluable diagnostic information. Learn to use it. ?Pay attention to WARNINGS as well as error messages. Although a WARNING message indicates a potential problem, your program will not abort.
?
GOOD HABIT #4: CODE FLEXIBILITY INTO YOUR PROGRAMS
Your programs will be much easier to maintain, modify and correct if you learn to use the tools and functions of IDE you are using. Learn to use macros, which make your programs easier to read, minimum problems caused by typing errors and eliminate the need to make the same changes in several files. Take advantage of the enormous library of SAS functions.
?
GOOD HABIT #6: DOCUMENT EXTENSIVELY
Documentation is extremely important, both for you and for those who work with your programs. Get in the habit of documenting what you've done as you do it. If you've been generous in using comments and labels and have organized your programs in a logical way, half of your documentation work will already be done. ?
?
CONCLUSION
There are probably as many ways to approach a programming task as there are programmers. However, the programmer whose code conforms to a consistent style will find it far easier to determine later what a program was written to do. Grouping similar statements together and putting them in the same place in every program makes them easy to find without having to search through several lines of code. A consistent scheme for naming variables, arrays and files often enables the coder to deduce meaning from names alone. Logic is far easier to follow if DO LOOPs, assignment statements and evaluations are coded the same way across programs.
There are, however, programming practices shared by good programmers, regardless of individual style. First, their programs are easy to read. Programs are well organized so that logic is easy to follow, and the good programmer is willing to sacrifice brevity for clarity when necessary. Second, good programmers write programs that are easy to maintain and change. They let their programs do the ‘heavy lifting’, avoiding tedious, repetitive coding when alternatives that provide flexibility are available. Finally, the good programmer thoroughly tests, checks and documents his/her programs and does not consider the work done until these tasks have been completed.
Not all habits are bad! The programmer who makes these habits his own will find his job easier and will certainly earn the gratitude of those who inherit his programs.
List of articles from the series:
CH 8) Errors & Habits
References:?Wikipedia, CMan(Bell Labs), GeeksforGeeks, guru99 and various other blogs, videos and sites on available internet.
If you find any errors or disinformation in this article, then please inform me.