Good Programming Practice

[kvarnerexpress 0]

I am creating a webs interface to a database which as you would imagine allows the user to search the database for soemthing, and on submitting search the results are shown. So far i have done this in just one .cgi program. I know i could have write 2 seperate programs to accomplish this task- i.e one passing parameters to another. My question is this- I'm going to have to make all the search results in a way such that you click on one and you display all the info on that particular result. But is it good practice to say have multiple .cgi files with them all linked by forms with an action that passes params to another, or have it all in one .cgi program?

[tuddy 0]

Depends, if you can handle trying to maybe debug multiple .cgi programs, its a better way to go, it has a more easy smaller flow through. It also allows for better intergration of new coding etc.

[stlgoalie 0]

In one of my PERL books it states: "In PERL there is always more than one way to do it!". In terms of what is good coding practices on wether to have one cgi file or several, that really is up to you. There really is no "right" or "wrong" way to do it. It really is your personal preference. I've heard it both ways, but to me, there is nothing worse that going through a PERL file that is 65k lines long trying to find a mistake. Sometimes I wish the main file just called subroutines from linked files. So if there is a problem with submitting, then its isolated to the few dozen/hundred/thousand lines of code in that file. So the answer here is, what ever you want so long as it works. Actually that's my motto to coding.

[fffanatics 0]

In almost every programming language it is better to have a new file for each new task. It just allows for better data abstraction and reusability of code. Plus, since there are different files, if you need to update one task, you dont risk changing the other one and you also know exactly where to look. If it just is you editing the code, it probably doesnt matter but in the real world where most programming is done, if 100,000 line programs were in 1 file, it would be sooo hard to work with or understand the code.

[Tyssen 0]

If it just is you editing the code, it probably doesnt matter but in the real world where most programming is done, if 100,000 line programs were in 1 file, it would be sooo hard to work with or understand the code.

I would've thought the opposite would also be true to a certain extent. If you have a dozen 10-line functions that all do similar tasks, wouldn't it be better to group them all together in a single file rather than have 10 individual ones?

[sonesay 7]

I think it can be either way depending on your preference and of those working on the project with you. There are cases where I find having all the code in one file good and others where it becomes too clutered so I would seperate them.

[Tetraca 0]

I would've thought the opposite would also be true to a certain extent. If you have a dozen 10-line functions that all do similar tasks, wouldn't it be better to group them all together in a single file rather than have 10 individual ones?

The goal in seperating code by files is to organize the functions by what they do so then you don't get confused. For example, in a CMS that I had written I have one main index.php file which passes parameters to the other PHP files. Each PHP file is organized by the task it performs - news.php dispenses news, admin.php reroutes all admin functions to their proper functions, securities.php contains all functions for security of the scripts. I couldn't manage everything if I had everything in one single file because if I did, it'd be 278 KB of text to sort through and I can't bookmark where each specific thing is.

The larger a program is, the better it is to organize it into seperate modules. If you have a small program that has 3 or so functions, there's no reason to organize your code into seperate modules.
Edited July 3, 2007 by Tetraca (see edit history)

[apicolet 0]

I totally agree with Tetraca on this. I would even go beyond : each time I write a program, even the simplest one, I separate functions and objects into distinct, coherent packages. Almost each time, it turned out later that I was right, because at least one the following thing always happens :- somebody will have make it evolve some day (the data you store needs some special post-processing in a certain case)- somebody will want to reuse one interesting component of it some day (writing another app that will access the same data)- someday, you will want to migrate a part of this to another way of doing the same thing (I used to store my data in plain text file, now let's use a DB, let's even use a new complex plugin architecture for data storage, without impacting the rest of the application)It's true that, when you have a program that would take 20 lines in a single file, it is a bit overkill to split it in 5 modules and define a whole object model and interfaces. I don't do it for throw-away scripts that I need to run only once !