programming best practice question

[rh71]

I do web programming and there are 2 obvious ways to go about implementing a new feature request. Is it a better practice to add onto existing code (the original file) and make use of IF statements, url params, and session vars to go to specific sections of the code? Or is it better to create an entirely new file [which may have a lot of similar code to start] for the new content? I'm thinking by creating a new file, it is easier to troubleshoot (readability) and also add further new related sub-features. If it is all kept in the 1 original file, it could balloon out of control where it is performing multiple tasks and over time we lose track of what went where and why. I make use of commenting, but it is time-consuming if it gets to be lengthy code.

What is the best way to go about it and why?

 

[Markbnj]

Are you just adding a new feature/code, or refactoring an existing one? In any case, adhere to the principle of minimality or "doing one thing well." Keep your files/modules, classes, and methods small and focused, and you'll have an easier time down the road.

 

[rh71]

It is a set of new features which is adding onto a branch of other features. For instance, I have a main page showing a user profile. Then a branch of that is to modify the profile (modify file). Now the new feature is if during the modification they input specific words, it should trigger a whole new set of text/actions.

Should I add that triggered part to the modify file or create a new file to handle that?

Sounds like you agree it should be new.

 

[KB]

New files would cause too many complexities. Lets say you create a new javascript file, which means you then have to touch every location that pointed to the old file and now point it to the new file. You can get around this having a stub script that calls all the latest scripts files, but then when you update the stub would you still create a new stub and point everything to it?

Second if you are duplicating code and you need to fix a bug, then you have to fix the bug in two places instead of one. There are times when you can eliminate duplicate code, which is always best practice, but it can be difficult, if its across different versions or features.

If you are using source control, managing your files will be a lot easier. For example most source control products allow you to see differences between the latest file and an older file if you are trying to see what changed. I hope you are using source control.

 

[nickbits]

factor out common code into a shared file and make a new file for the new function

 

[douglasb]

Is inheritance an option?

 

[BrightCandle]

The two areas that determine what should go together and what should be apart is based on cohesion and coupling. Items belong together because there are towards the same functional area have cohesion and likely should be coupled together and be close to each other in the software. Items that aren't part of the same functional area in the software should be separated, loosely or not at all coupled and thus have no cohesion.

So when you add a feature you have to ask what its like, what its not like, what it needs in terms of dependencies and what depends on it and determine where it fits within the software. Then you have to refactor the existing code to couple and decouple the various aspects for it to slot into a place where it fits cohesively.

Study those two terms and it will become clearer what should go together and what should be separated.

 

[Rakehellion]

I do web programming and there are 2 obvious ways to go about implementing a new feature request. Is it a better practice to add onto existing code (the original file) and make use of IF statements, url params, and session vars to go to specific sections of the code? Or is it better to create an entirely new file [which may have a lot of similar code to start] for the new content? I'm thinking by creating a new file, it is easier to troubleshoot (readability) and also add further new related sub-features. If it is all kept in the 1 original file, it could balloon out of control where it is performing multiple tasks and over time we lose track of what went where and why. I make use of commenting, but it is time-consuming if it gets to be lengthy code.

What is the best way to go about it and why?

You say creating a new file will involve duplicating code. Never do that. All the similar code should be in its own file to modfify as necessary.

If it's a minor tweak to an existing system, modify the existing file. If it's something completely different that doesn't really fit in with anything you already have, create a new file.

 

[Cogman]

If you have 2 files that share code, you should have 3 files. 2 with unique code and 1 with the shared code. If sharing the code makes things look nasty, the code needs to be refactored, it is likely doing too much.

Don't repeat yourself. Keep it simple.

 

[Leros]

This forum does stuff like this:
http://forums.anandtech.com/profile.php?do=editsignature

profile.php probably has a giant if-else-if chain like :

if (do == "editsignature") {
   // do stuff to edit signature
} else if (do ==.... ) {
} else if ....

Don't do that. Each of those pages should be their own PHP file.

If you have commonality, extract it out into a utility file.