Dangerous Programming.

A sense of good programming practice develops through extensive experience .The programming can be taught but the etiquette of programming one learns from his or her own mistake. 
In course of your programming pursuit, I am sure, you must have some occasions, when you landed yourself in an island from where the path of graceful exit suddenly disappeared. How did you come out of the island? In so many of such cases, the story of escape appeared me adventurous but sorry to say –‘not elegant’. Nevertheless, as a programmer you know that the story will be scripted and it shall be read by your posterity (maintenance engineers) in order to carry on your task. Can you realize what sort of legacy you are transferring to them? They will spend so many sleepless nights to understand your state of art and therefore, for them, making a slight progress on your program will be an uphill task .You dug the grave for yourself and built a hell for themselves. Your critiques (test engineers) will face no difficulty to defame you and to perish you. This is a programming predicament. No one likes to follow the path of perdition, which eventually lands you, as a programmer, in the deadly island. Do not follow the path of hell. It is not prudent to astray first and then think to come back to follow the divine path. It might be too late. You should verify the path intermittently to ensure that you are moving in the right direction. So, when you program, don’t code first, rather verify it first. Dave Gelprin and Bill Hetzel have valid reason to suggest –“Test,then code.”
In this article, I will discuss some programming -mantras, which is independent of any programming languages. This will help you all along in your programming journey and thwart your temptation to pick the wrong turning on your path. Here, I am going to set the alarm bell against each mantra, so that, it just starts ringing the moment you enter into the dangerous- programming- zone. 

Behavioral issue:

·        If you start coding immediately after the task is assigned to you and don’t wait till the low level design of the program gets ready and formalized, the alarm bell should start ringing.

 “Have a road -map with you before you embark on your mission.”

·        If you seek comfort during writing the program and are quite unconcerned about those who might have some interest in your program, then you are certainly an individualistic. You are vulnerable also. This is alarming. The alarm bell should start ringing.

“In life one should always guard himself against lurking foe (tester) and be benevolent to his friend (maintenance engineer)”.

Program style:

·         Read your code intermittently .If your program appears more like an essay than a set of instructions, or in other words, if you need to drag the scroll bar right or left in order to read your own code then alarm bell should start ringing.

“ If your instructions are not ordered well, the chances of misinterpretation are greater;”

·         If you are leaving your code, which implements the specific feature of your application, without the associated comment, then alarm bell should start ringing.

“A preface is necessary to understand the theme of the story”

·         If the comment is not about –‘what it does’, rather it is about -‘how it does’, the alarm bell should start ringing.

“A preface is preamble, not the whole story”

·      If you feel that the abstraction of your code is little bit inconsistent with the associated comment then let me warn you that other interested party will see this inconsistency through a magnifying glass .You might appear telling lie. The alarm bell should start ringing.

       “Perjury, however mild, is an offence. “

Naming issues.

·         If the name of your variable, method and module do not manifest their purpose of existence (what they are meant for?) in your program, the alarm bell should start ringing.

                                 “More covert a person is, more difficult it is to understand him.”

·         If your variable-name doesn’t disclose the type to which it belongs, the alarm bell should start ringing.

                                “Every religion has its own prescribed code of conduct.”

 ·        If your variable or method- name does not describe their scope, the alarm bell should start ringing.

                               “Searching the baby becomes easy, if we know how far can he/she can go.”

·         If you do not maintain the consistency in naming of variables and methods or say, the naming convention does not distinguish between variables and methods and also fails to distinguish one type to another, the alarm bell should start ringing.

 “Impersonation is an offence”

Declaration and definition of variables and functional-unit (function/method/module).

·         If you repeatedly feel the need to define the global variables, which is either refereed, or modified by so many different functions, the alarm bell should start ringing.

“Talking so much in public place can violate your privacy”

 ·         If you do not define your variable and relies upon its default value and also do not dispose the variable, once you finished with it, the alarm bell should start ringing.

“Life precedes the death and death precedes the life; this is the nature and it is stable, so make your program as stable.”

·         If you are feeling stress in tracking the variable, which you have declared, the alarm bell should start ringing.

“If you, yourself cannot track your so many opened account numbers, you can not expect your generation –next to operate them.”

 ·         If you are declaring unrelated variable at the same place, the alarm bell should start ringing.

“The worst kind of inequality is making of unequal things equal.

·         If the size of your function/method is exceeding more than 25 line of code, the alarm bell should start ringing.

“More we grow in age more the complexity creeps in our life”

·         If you feel the need to of copying the code from one method/function into another, the alarm bell should start ringing.

“You have recruited two cooks; one who cook and other who cooks and serves.”

·         If the formal parameter-list in your function/method has more than five arguments, the alarm bell should start ringing.

“Information Overload complicates the action. "

 ·         If the argument in parameter list of your method is data structure or rather more complex type, the alarm bell should start ringing.

 “Biting more than you can chew is not only the wastage of food but can also create complication for your digestive system.”

 ·         While defining various functions in your program, if you repeatedly feel the need to refer a particular functional-unit (function/method/module) and that functional-unit is not at the bottom of the hierarchy of the architecture, then the alarm bell should start ringing.

 “Your mid level manager seems to be more versed in primitive work; demote him to the bottom of the hierarchy.”

 ·         If some functional-unit is interacting with your another functional -unit which is neither preceding nor succeeding it, then alarm bell should start ringing.

 “Someone is interfering in your life for which he/she is not legally authorized.”

 ·         If one functional –unit is modifying the local data of another functional-unit, then alarm bell should start ringing.

“Adultery is a cognizable offence.”

 Control Construct:

·         If your control construct (selection, iteration, and sequencing) has more than one-entry and exits points (using break, exit, continue, goto, etc), the alarm bell should start ringing.

 “Open border paves the way for infiltration and escape for mercenaries.”

 ·         If you are using deep nesting of control constructs or deep nesting try-catch, alarm bell should start ringing.

 “Your fine knitted cob-web will knit the brows of many.”

 ·         If the predicate in your conditional statement consists of number of logical operators, the alarm bell should start ringing.

“More the constraints you have in your life, more unpredictable your life is.”

 Class and object:

·         If your class is heavier than normal (having so many methods or having methods of significantly higher size and complexity), the alarm bell should start ringing.

 “You know- jack of all trades is generally master of nothing”

 ·         If your class is coupled with many other classes or a long chain of methods is invoked in response to the message received from another class, then alarm bell should start ringing.

 “Depending so much upon the supplier and practice of bureaucracy in rendering the service can make your production unmanageable.”

 ·         If you are declaring data member of the class as public or you are tempted to use friend-like function, the alarm bell should start ringing.

 “If you do not bother for the security of your own property, you might be robbed even by your friend”

 ·         If you are inheriting the class just for the sake of reusing the code and the subclass does not represent the definite concept in your architecture, the alarm bell should start ringing.

 “Simply copying the accent doesn’t make you Dutch. ” 

 ·         If the methods in your class access quite different set of set of instance variables of the class, the alarm bell should start ringing.

 “Diverged personal interest of each member results in a weak and unstable family.”

 ·         If an instance of your class is directly accessing the component of another class, the alarm bell should start ringing.

“If you let your client a free access to your employee, he can overtake the functioning your company”.

 ·         If you are inheriting from multiple interfaces and the method -names in two or more interfaces are common; the alarm bell should start ringing.

 “You call Dr. Jakyll but Mr. Hyde may appear to your dismay; you must call the right incarnation.”

 Verification, validation and testing.

·         If you are not writing the code to validate the imported data and simply using it as you receive it from external source, the alarm bell should start ringing.

“You must check the visa permit of landing foreigner before letting them enter in your country”

 ·         If you are not catching the arithmetic exceptions, the alarm bell should start ring.

 “Before solving a mathematical equation, you must know the domain of the equation.”

 ·         If you are not catching the overflow exceptions, the alarm bell should start ring.

 “The flood can destroy your hard sown crops.”

 ·         If you are not conducting the test on boundary of different classes of input, the alarm bell should start ringing.

 “The possibility of slippage is greater at the culmination.”

 ·         If you do not get your code reviewed by third party, the alarm bell should start ringing.

 “The state of art -however brilliant, is useless, unless it is understood by other and serves the desired purpose.”

Conclusion:

This article is not complete; it can’t be. In fact, no such article can ever be complete as every new programming language which addresses the contemporary issues bring along with some new issues which is first tackled either by self -discipline or by the individual brilliance, until the next generation language comes up to resolve them. But one thing is certain –the term programming should now be better understood as term-‘planning’. It is easy to program today –thanks to the modern sophisticated programming environment and framework, but chalking out the plan or design for the program, which meets the quality criteria of the system, will always remain an issue. This is the quality- criteria that dictate the rule for programming. Since the quality criteria varies system to system, so the programming style; and therefore, in turn, programming guidelines varies system to system. And this is the reason you have come across so many articles like – ‘how to write maintainable program’, ‘how to write secured code’, ‘how to write robust code’ and many others like them. However, this is hereby not to submit that the list of programming guidelines is unique for each system but to suggest that some rule are more important over others and it depends upon the quality criteria of the system. And the set of such programming - rules, which is more important for a particular type of a system, need to be elaborated in terms of programming style. There are some rules, which gradually become irrelevant because programmer knows it by his/her birth. One such kind of rule is –‘avoid goto statement’. Even the rookie despises the goto statement. And also there are many other rules, which are more or less relevant to every kind of programming approach, irrespective of the type of the system you are developing. Because every system must meet certain quality criteria such as –maintainability, testability and readability. This article has been written by taking account mostly of these kinds of quality criteria.

References:

1.Pankaj Jalote: An integrated approach to software Engineering.
2. Roedy Green: How to write unmaintainable code.
3. Boris Beizer: Software Testing Techniques. 

Biography: Over six years of experience in teaching and training of software engineering’s application on various Microsoft technologies which includes VB, COM, DCOM and .Net. Currently working as a Project coordinator in the same organisatation.

Email: s_suripunj@rediffmail.com