Software Programming Process Archives > Software Programming Process
Part 3: Generalized programming method
This article was written by a software professional at Stylus Systems, Bangalore India. We hope that you benefit from the information shared here and that you consider our services. Please feel free to email us.?
There is no standard method for developing programs, whatever the level of complication. Flow charts are very handy for explaining an algorithm, but when it comes to developing them, the actual text editor is a lot handier to keep experimenting with, than a flowchart on paper. And it becomes a lot easier if you can compile and run your program at the same time to check for syntax or logical errors as you're going about it. Of course, for a very complicated algorithm, a paper and pencil would be very handy in keeping the broad picture in mind. So it's a personal thing really, developing programs.
The catch is when others have to maintain and change programs you've written.? Always keep in mind that not everyone around is a genius like you. (If that's tough, try going through a really large project someone else has developed after deleting all the comments and removing all indentations.)
They might need a little help in the way of comments, proper structure for the text in the code (source code), meaningful names for variables, functions, classes, objects and all other non-keywords. In short, we need STANDARDS for these things.
Generalized programming method:
1. Defining standards
So here's where we get down to business. I'm it breaking up into
Commenting source code
Indentation of source code
Naming conventions for all non-keywords
Programming techniques (actual logic used)
I quote here from instructions for a web development project called WorldImages. We just completed this project for a client.
QUOTE
All code needs to be commented. This is compulsory. All logic, complex or otherwise needs at least one small line, which in English explains what's supposed to happen. You don't need to comment on every line of the page, you could write one brief explanation for the next 10 lines of code... Or something similar so it helps another programmer debug.
Indents to be perfect - do not use spaces; instead use one tab for each level of code.
Naming Conventions:
Object
Prefix
Object
Prefix
Form
frm
Field collection & Object
fld
Textbox
txt
Query
qry
Checkbox
chk
Object
obj
Option button
opt
Recordset
rs
Command button
cmd
Boolean
bln
Image
img
Label
lbl
String values
str
Table
tbl
Numeric values
int
Database
db
Constants
cnst
Databound Listbox
dbl
Listbox
lst
Hidden
hid
All SQL queries need to be in capitals. For example, "select * from tblwhatever" is not accepted. It should instead be "SELECT * FROM tblWhatever".
Although not necessary in PHP, try to close all objects you open - arrays, database connections, record sets, etc. Although PHP has some support for garbage collection, try to do this manually.
Local variables are variables that reside within subroutines and functions (this is known as local scope). These variables are compiled into numeric references and put in a table. Local variable references can be resolved at compile time. Global variables are resolved at run time. This means that local-variable access is many times faster than global-variable access. Also, un-dimensioned global variables are the slowest of all -- the first time an un-dimensioned global variable is used, the entire object model is searched for an object with that named property before a new one is created. So use local-variables to get that better performance.
All files have to start with the following header:
<?php
/*
Author:
Purpose:
Modifications:
- by xyz on xx/yy/zzzz, to add xxyzyzy
*/
?>
Basically, Author says who created the page. Purpose tells what the page is intended to do. Modifications is filled in by somebody who is not the author of the page, but has edited the page for some reason. If this is the case, they would need to add a line in the Modifications section with one-line about what they came to do.
Do not use more than one database connection per page.
Declare all your variables at the top of the page
UNQUOTE
As you can see, all the standards here were predefined and that makes interchangeability of modules between programmers very easy. Also we have a ready reference for future teams involved in maintenance.
Whether you comment your code during the coding itself or after the final test is really a function of the size of the code itself. (In a large program, one has a tendency to forget why one did declare a particular variable 400 lines back in the first place.) In large programs, comments help the programmer himself in keeping tabs on the whole code. But in smaller projects, it's more efficient to finish all the code and then add the necessary comments for an outsider's reference.
Regarding indentation, the two popular styles in vogue right now are
1) 'C' style
for(i=1; i<1000000;I++)
{
????? k = sqrt(i);
????? for (j=2;j<k;j++)
????? {
?? ???????????if (i%j)==0
????????????? {
???????????????????? printf("%d is a prime number \n",i);
???????????????????? break;
????????????? }
?????? }
}
2) Java style
for(i=1; i<1000000;I++){
????? k = sqrt(i);
????? for (j=2;j<k;j++){
????????????? if (i%j)==0{
???????????????????? printf("%d is a prime number \n",i);
???????????????????? break;
????????????? }
?????? }
}
The 'C' style seems to be more popular probably as it's easier to follow (sometimes it's difficult to spot the opening brackets in java style) and 'C' has also been around for much longer.
In logic building, there are a number of lesser known and neglected issues like
Among all the basic operations in the processor, +, -, *, /, =, ==, <, > etc, it's the comparison operators (like the last 4) which take the maximum time. So the more the number of conditional statements in a program, the slower it runs.
Increased use of variables means the program will use a larger amount of memory to run. On the other hand if program logic is twisted to accommodate lesser variables, the program will run slower. Reuse of variables helps but can be confusing.
Use of functions reduces the size of the source code as well as the executable, but function calls take time. (In C there is a provision for 'inline functions' which are incorporated into the executable in every place the function is called, but that's still only halfway there.)
Most of these issues come into focus only in very large programs where execution time, file size and memory available have to be considered and one has to be compromised in favor of the others. Most of the time, all these three are compromised in favor of a variable I haven't listed here, time taken for coding. But it is a factor too.
Conclusion
The importance of following standards in professional programming cannot be overemphasized. It is as important as the programming itself, maybe more. A solution no one understands is of no use.
There really are a lot more factors that come into play. Time and resources available can be listed as a major one. But true programming is an art that needs time and patience to master. There are no standard methods for coming up with a sure fire solution to a problem or any absolute criteria for measuring the skill of a programmer.
A program is the fastest only till someone comes up with something faster and a problem is insoluble till someone comes up with a solution. But like any art, this field offers a whole world of possibilities to explore and challenges to face. And for a true programmer, the simplicity of the algorithm that can be developed comes before all-else. Simple algorithms take care of all the other issues, time, space, everything. But the most difficult problems to solve are the ones that have the simplest solutions.
