CajunCenturion
Programmer
A while back, we had a thread dedicated to Idiot Proofing Programs. This thread seemed to run down two paths. The first path was to essentially get a better class of idiots. Amusing and entertaining, this unfortunately also has some truth behind it. The second path dealt with getting accurate functional requirements up front in writing, and so forth. Excellent points were made, but this isn’t really the job of the programmer – it’s the job of the analyst. I am aware that most, if not all of us, wear both hats (analyst and programmer) from time to time, but what the previous thread lacked was a path that dealt with how programmers can write better programs. Assuming that the analyst has done his/her job, and that we have been provided a good, complete, and accurate functional requirements specification, I now pose the following paraphrased question:
How do we write an Idiot-Proof Program that meets those specifications?
Obviously our logic must be correct, and we need to have error handling to deal with unexpected inputs, but does our choice of control structures (Do While vs For Each) make a difference?
Found = False
For Each Item in Items
If Item.Property = “What We Want” Then
Found = True
Exit For
End If
Next
Found = False
Index = 1
Do While (Index <= Items.Count and Not Found)
If Items(Index).Property = “What We Want” Then
Found = True
Else
Index = Index + 1
End If
Loop
Does the complexity of the code make a difference – not just for the sake of performance, but for the sake of program testing and validation? From a purely Software Engineering standpoint, the For Each with Exit For statement is more ‘complex’ because the Exit For is an additional branch that must be dealt with during program testing and validation. It’s another path thru the code that must be taken into account. Or is this simply a matter of style? This is a very simple case, of course, and if your answer is different because it’s a simple case, then at what point does the case not become simple enough to warrant legitimate consideration of alternatives in light of program complexity?
Does having functions and procedures have single entry and exit points affect program complexity, thus in turn leading to easier or more difficult programs to write, test, and/or maintain?
What other programming “guidelines” (indendation, variable nameing, modularity, single-function procedures, program routes, modularity, object oriented, <add your own list>, etc, etc) have their roots in providing mechanism by which we as programmers can write better, (or more idiot-proof) programs? What “guidelines” matter to you?
All opinions and comments welcome. There really are no wrong answers here.
Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
How do we write an Idiot-Proof Program that meets those specifications?
Obviously our logic must be correct, and we need to have error handling to deal with unexpected inputs, but does our choice of control structures (Do While vs For Each) make a difference?
Found = False
For Each Item in Items
If Item.Property = “What We Want” Then
Found = True
Exit For
End If
Next
Found = False
Index = 1
Do While (Index <= Items.Count and Not Found)
If Items(Index).Property = “What We Want” Then
Found = True
Else
Index = Index + 1
End If
Loop
Does the complexity of the code make a difference – not just for the sake of performance, but for the sake of program testing and validation? From a purely Software Engineering standpoint, the For Each with Exit For statement is more ‘complex’ because the Exit For is an additional branch that must be dealt with during program testing and validation. It’s another path thru the code that must be taken into account. Or is this simply a matter of style? This is a very simple case, of course, and if your answer is different because it’s a simple case, then at what point does the case not become simple enough to warrant legitimate consideration of alternatives in light of program complexity?
Does having functions and procedures have single entry and exit points affect program complexity, thus in turn leading to easier or more difficult programs to write, test, and/or maintain?
What other programming “guidelines” (indendation, variable nameing, modularity, single-function procedures, program routes, modularity, object oriented, <add your own list>, etc, etc) have their roots in providing mechanism by which we as programmers can write better, (or more idiot-proof) programs? What “guidelines” matter to you?
All opinions and comments welcome. There really are no wrong answers here.
Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein