Don't of Good Programming style

Now,  we will  consider the second  aspect  of good programming  style i.e. don't  of good programming  style. Here we will discuss the rules  which  should  be avoided to  be happened or which  require special consideration. The don'ts  of good  programming  style  are listed in table6.9,

Rule 2.1: Do not be Too Clever

Simplicity is  the key  element  for the  successful completion of the program. So  if a programming  language doesn't support  some feature then  don't  be clever to create  in an  artificial or unnatural form.  To  understand this  concept, look at the  following example.

Example 53. Consider the following program signet of FORTRAN IV illustrated in fig 6.28.

This code is so obscure and inefficient. Followings code segment  of fig  6.29 achieves the same  result in a clearer and more efficient manner:

In this second efficient  code, algorithm  makes obvious the initialization of  matrix using N extra assignment statement. However in the  first inefficient code, it requires an  integer multiply operation, two integer division operation and a floating point  for each  of the elements in  the matrix. That is why the second one is more efficient than the first one.

Second aspect  related  to this  rule  that we  should  not try to  create the  shorter  program only to save some lines of code. Because it is not essential that the better or fastest of two  programs will be the shorter of two. The better program should be clear, simple easy to use understand and read. Therefore shortcuts tricky codes and complex algorithms should  be avoided they  may lead to errors and reduce readability .that why  we should only those feature which we know properly. Misuse of feature is worse than not using that feature at all.

Rule 2.2: Avoid null Then Statements

This rule implies  that we  should always  write some  statements  in then  part of if then or if then else constructs. To understand it. Consider the following examples.

Example 54.   Consider  the following sample program shown in fig 6.30,

The if condition shown in fig  6.30, doesn't  mean s\anything because  if condition is true then  what it  will do.

Example 55 . Consider  the sample program of fig 6.31,

Which is equivalent to :

If ( not condition 1)

Then S:

The result was not  our motive. So we should  not probably write  a null then  in such manner.

Rule 2.3: Avoid Then IF Statement

We should avoid  the writing of  if just after then. It is better to use else if forms in place  of then if  statements .

Example 55. Consider following program segment shown in fig 6.32,

Now, we will replace this then if by else if forms then it will  look like as illustrated in fig 6.33

This replacement is more clearer and obvious form.

Rules 2.4: Do not Nest Too Deeply

The different  control constructs particularly the if  then if else  can be  nested. If the  nesting  becomes  too deep the  program  become harder to understand. In case of deeply nested if then else s, it  is often  difficult to determine  the if statement  to which  a particular else clause  is associated. Whatever possible deep nesting  should  be avoided, even if it means  a little  inefficiency. Now consider some of the cases.

Case 1 consider  the following construct  of nested if then else s

If the different  conditions are disjoint, this  structure  can be  converted in following structure  of fig 6.35

This sequence of statement  will produce the  same  result  as the earlier sequence but  it is much easier to understand.

Case 2 : consider the following  java program segment  which  is so badly  formatted.

A properly formatted version appears in fig6.37

When faced with  complex  code containing  the if -if  construct one  way to simplify if is to make  use of  the fact  that the  if - if  combination.

If<condition1.>

If < condition 2>

Is equivalent to the  single  condition

If <condition 1>and <condition 2>

Case 3 : The case 2 program  segment  can now  be rewritten as shown in fig 6.38,

So nesting if statements too deeply  leads to  code that the difficult to read. As  rule  of thumb  if statement  nested to  a depth  greater than  three is poor programming  practice and should be avoided.

Rule 2.5:Avoid Obscure side Effects

When  s subprogram  is called  it sometime has some side effects  of modifying  the  program  state  beyond  the modification  of parameters listed in the  subprogram interface definition  for example modifying global variables. Such side effects should by avoided where possible  and if a subprogram has side effect they  should be properly  documented.

Rule 2.6 Don't sub optimize

When a programmer gives so  much  of his  attention to a less  effective situation then it leads to the  sub optimization. As  such no  one knows that  which  part of the program will take most of  the  execution time  or very  important to be concentrated or which part won't be. So  one  should choose the optimal approach if  it is obvious  and  he should  not try to sub optimize about  the programs.

2.7: Carefully examine Routines having More than  five  Formal  Parameters

A subprogram  or routine with  a complex  interface should be carefully  examined. Such subprogram might not  be functionally cohesive and might be implementing multiple  functions. As  a rule of thumb any module whose interface has  more than five parameters should  be carefully examined and broken into multiple subprograms with a simpler interface, if possible so that  subprogram clarity and readability  can be increased.

2.8: Don't Use an Identifier for Multiple Purposes

Programmer sometimes use one  identifier to denote several  different entities. A common  name must not be  used to mean  two different  things  places. It is a dangerous  practice because it makes  the source code very sensitive to future modifications. Additionally use of an identifier for multiple purposes can be extremely confusing to the reader of a program. And additionally it uses memory inefficiently. So  each identifier  in a program  should be given a unique  descriptive name  which suggests its purpose.

If a system  is so tightly constrained in memory space that single identifiers must  be used for multiple purpose the system should be segmented into several smaller routines with  an overlay structure. If this violates execution time restrictions the system should be redesigned.

Rule 2.9: Don't leave to consider the Possibility of Undesired and Unexpected Conditions

A program is robust if it does something planned even for exceptional undesired or unexpected situations. A  program might encounter exceptional in such forms as in correct input, incorrect value of some variable  and overflow. A program should try to handle such situations. In general a program should check for validity of inputs where possible and should check for possible overflow of the data structures. If such situations do arise the program should not just crash or core dump it should produce some meaningful message and exit gracefully. 

Rule 2.10, Avoid the Non Portability of the software system

The software  system  should not be completely  hardware dependent it should provide the portability. If  we make use of  system utilities in extent it makes the software less portable. Therefore when portability is a requirement  if the software product, the use of system utilities should be minimized. Once more benefits of system utilities is that they can  reduce the size  of the  software and make  it more efficient .

Latest technology based Software Engineering Online Tutoring Assistance

Tutors, at the www.tutorsglobe.com, take pledge to provide full satisfaction and assurance in Dont of Good Programming Style homework help via online tutoring. Students are getting 100% satisfaction by online tutors across the globe. Here you can get homework help for Dont of Good Programming Style, project ideas and tutorials. We provide email based Dont of Good Programming Style homework help. You can join us to ask queries 24x7 with live, experienced and qualified online tutors specialized in Dont of Good Programming Style. Through Online Tutoring, you would be able to complete your homework or assignments at your home. Tutors at the TutorsGlobe are committed to provide the best quality online tutoring assistance for Software Engineering homework help and assignment help services. They use their experience, as they have solved thousands of the software engineering assignments, which may help you to solve your complex issues of Dont of Good Programming Style. TutorsGlobe assure for the best quality compliance to your homework. Compromise with quality is not in our dictionary. If we feel that we are not able to provide the homework help as per the deadline or given instruction by the student, we refund the money of the student without any delay.