Incessant programming bugs

[elvisbozz]

I don't know much about programming, per se, but I have a site written with Smarty where the previous developer looks to have written sloppy code. Every few weeks a new bug is uncovered. Yet, they often claim that they cannot seem to fix it. Or when they do fix it, they do a sloppy job with the fix, which leads to bugs of its own.

The site, as whole, operates relatively smoothly, but whenever I've asked another developer to come in to work on a bug, I hear all sorts of comments regarding the past coding and the potential vulnerabilities it has.

I want to bring in someone new to start expanding the site, but am unsure on how to approach the recurring liabilities of the previous coding.

Rather than bringing someone in to do a full re-coding of the past work, is there such a thing as having a 3rd party do a 'code audit' or something similar on my site? Not sure if there's a better industry term for such a thing, if such a practice even exists.

Any advice on how I could approach this dilemma?

[spikeZ]

Hi Elvisbozz and welcome to the forums

It's a tricky position for you and for the other coders who are looking at the script. It is very rare for folk to progam in an identical way so it might look good to one person but to someone else it seems illogical and wrong.

If the vunerabilities are a serious security risk then get that part rewritten asap. As for the rest, the more you patch up something sloppy the worse it will be in the long term.

Would it be an option to have parts rewritten or is it just one big sloppy mess?

As for the Audit type company - I dont know any but if you give me a few days I might set one up!!!!!!!!!!

Spike

[Kailash Badu]

As for the Audit type company - I dont know any but if you give me a few days I might set one up!!!!!!!!!!

Good luck with that one spikez.

omniTI has essentially been doing the same thing (chris shiftlet), but I expect the service to be pretty expensive.

[spikeZ]

^ well thats my idea out of the window then

[bokehman]

whenever I've asked another developer to come in to work on a bug, I hear all sorts of comments regarding the past coding and the potential vulnerabilities it has.

Isn't this just the same old story? It doesn't matter whether it's a builder, plumber, electrician, mechanic, web developer, etc they all tell this story (normally preceded by a sharp intake of breath for extra effect).

Consider this: How much security does your site need? Are you storing sensitive data? Does it really matter if it gets hacked? And if you are hosting on a shared server you might as wel just forget about security because it doesn't exist.

And if it is not security you are bothered about wait until there is a real problem before believing something needs "fixing".

[cranial-bore]

As mentioned all developers will have a familiarity curve to overcome when viewing someone elses work. The important thing is to differentiate between different styles and actual, dangerous code. There's also a wide spectrum of code quality relating to simplicity and maintainability that won't directly affect security.

Given the comments you've had it's highly likely that a code audit would reveal problems. If so you're likely to be paying for the audit plus a rewrite.
It may be cheaper (but not cheap) just to get a rewrite without the audit.

The most economical path depends on how bad the code is. If it's really bad then a complete rewrite will probably be cheaper and give a better result that trying to patch a sinking ship.
If it's structurally sound, but with a lot of smaller issues they may be correctable.

[joebert]

I hear all sorts of comments regarding the past coding and the potential vulnerabilities it has.

Why on earth did you hire a salesman to fix your website ? lol

If it ain't broke, don't fix it.
If it is broke, get a new one.

[jimbo_dk]

Now if you look at my code you might find it to be pretty bad, and that’s normal, pretty much any programmer that looks at almost any other programmer’s code will judge it to be a pile of offal and then proclaim that the only way to fix it is to rewrite it. (I wonder why this is?)

From
http://kickin-the-darkness.blogspot....rogrammer.html

Judging by your comments about the bugs though, it does look like it would be better to ditch the old architecture and start again.

[php_daemon]

Isn't this just the same old story? It doesn't matter whether it's a builder, plumber, electrician, mechanic, web developer, etc they all tell this story (normally preceded by a sharp intake of breath for extra effect).

Consider this: How much security does your site need? Are you storing sensitive data? Does it really matter if it gets hacked? And if you are hosting on a shared server you might as wel just forget about security because it doesn't exist.

And if it is not security you are bothered about wait until there is a real problem before believing something needs "fixing".

Why on earth did you hire a salesman to fix your website ? lol

If it ain't broke, don't fix it.
If it is broke, get a new one.

Exactly my thoughts.

Noone has the right to disrespect someone elses work, and those who do belong to hell.

[raananSchwartz]

" coders life " how complicated

[Kon-Tiki]

The guy who did my job before me really was a bad coder. His mail-form comments existed out of regular expressions like (\r), with as result on that: "**** off Yankee!" when it matched. The rest of his code was bits and pieces of free scripts he plucked off the net and copy-pasted together. His idea of CSS was rewriting it all in each and every file (which caused some inconsistencies in links and looks, especially in the footer).

Another thing is, even if the code might work and the security holes wouldn't be a big thing, and even if it's sloppy code, if the thing simply doesn't do what it should do, it's useless. The guy before me installed OsCommerce as webshop (but didn't quite configure it all yet), but the database should be the same as the accounting program, so there goes the idea of a premade package He worked on that from May til end of August, but all that's got to be tossed out, simply because it doesn't do what it should, or would take too long to patch up.

[Hammer65]

It's impossible to tell without looking over the code, to what degree a re-write would be required. There may be sections that can just be fixed. It's pretty likely however, that a re-write would be in order.

If a re-write of the whole site isn't in the cards, it may be able to be done in pieces, but that depends entirely on how it is currently structured.

What part of it is a mess? The database (very common)? Not enough code in functions or classes? Use of register_globals? Some of that can be fixed, including the CSS issue you mentioned.

[jimbo_dk]

The guy who did my job before me really was a bad coder. His mail-form comments existed out of regular expressions like (\r), with as result on that: "**** off Yankee!" when it matched. The rest of his code was bits and pieces of free scripts he plucked off the net and copy-pasted together. His idea of CSS was rewriting it all in each and every file (which caused some inconsistencies in links and looks, especially in the footer).

Probably a 16-year old (yes, I'm being stereotypical). No offense to some of the great 16 yr olds in SP though. I hear horror stories like this from clients from time to time. But this is usually when they are on tight budgets and looking for a 'cheap freelancer'.

[Czaries]

A lot of code looks sloppy to other people, because everyone has different coding styles. From a security standpoint, the sloppiness doesn't really matter too much as long as it functions as intended. Generally, if you can turn OFF 'register_globals' and 'allow_url_fopen' and the script still functions correctly as it did before, you should be OK.

Now, from a maintainability standpoint, you do seem to have some genuine problems here. There are two major sources outlining coding standards:
1. PEAR
2. Zend
If these coding standards are followed, generally other developers have no problem reading the code. There are some cases where even if these standards are followed, the site and its functionality is not put together in a way that makes good sense, making it hard to follow the logic (like single functions who's work spans across multiple different other functions in several different included files).

If you plan on doing a lot of extra work and adding more features to this website in the near future, than you may have a problem and need to have it re-coded. If you are OK with the site now and you don't plan on adding a slew of new features anytime soon, than it's probably best to stick with it at least for a little bit so it's not a total waste of money (unless it really does have some serious security issues).

[Kailash Badu]

if you can turn OFF 'register_globals' and 'allow_url_fopen' and the script still functions correctly as it did before, you should be OK.

Well, 'register_globals' and 'allow_url_fopen' make up only a minuscule part of potential security vulnerabilities. There's a lot more to security than just that. There are are plenty of other common vulnerabilities that should be addressed in a common application. However, the point is how secure your application needs to be? nothing will be foolproof for sure.

[Hammer65]

You take the security measures that are appropriate for what you have to protect. Keep in mind, that that includes the server that the site is on. "They" would love to have your machine to play with, so it's not just about your data.

I don't want to be critical in saying this especially since someone already mentioned the Zend and PEAR coding guidlines, but I do think there is something interesting about the responses in this thread.

We have some pretty big knock down drag out threads on this forum about coding standards and standards compliance. It's interesting see some give so much slack over sloppy code.

Obviously none of us but the OP has seen the code in question, but I have found that different style, rarely has as much to do with the mess as actual mess. I don't feel comfortable lecturing someone on "proper" standards, but I think in general there are issues of structure, comments and such that we can all agree make better code.

The Zend and PEAR guidelines are an excellent read for any PHP programmer. Where you put your curly braces I think is up to you, but that really doesn't relate to messy code IMHO.

[PMichaud]

I haven't seen the code but given the percentage of code that sucks in general, if you have had multiple people telling you it sucks, plus bugs crop up in it all the time, you're probably looking at a pile of crap code. If you want to risk future expansion by building on a shaky foundation, then that's your choice, but you won't get sympathy from me. Doing that would mean you haven't learned your lesson from the first time you got what you paid for!

[Kon-Tiki]

Argh! Get this... The day I started, I got this bundle of papers my predecessor left behind, which contained all information on servers, databases, etc.

Now, one of the sites I got to make is pretty much done, and I want to put it on its production server, so I open the FTP client and load the site up.

I then go to add the database tables, and... I can't find any information on how to access that server's database! There's information on only one server's database! GAH!

[sporkit]

At my office we used smarty to try and streamline the development process. In the end it just was a huge mess and were digging around 5-6 files just to add a few small features.

[Hammer65]

Smarty can't help you structure a project properly. I haven't seen the same problem, even with large sites.

[bokehman]

It's interesting see some give so much slack over sloppy code.

That is not what anyone is saying. The OP is at a major disadvantage because he has no way to know if the developer is telling the truth about the code.

It would be different if the person inspecting the code was unbaised and was not going to make any financial gain through "repairing" it.

[Jake Arkinstall]

Probably a 16-year old

Lol.

Anyway, I'm always up for fixing sloppy code if you need it - I've had people PM me for the job, and where happy with the results. (of course, I do expect some money for it, lol. usually about £100 ish, depending on the scale and sloppiness of the code)

[Hammer65]

That is not what anyone is saying. The OP is at a major disadvantage because he has no way to know if the developer is telling the truth about the code.

It would be different if the person inspecting the code was unbaised and was not going to make any financial gain through "repairing" it.

What I am referring to, are comments like this

It's a tricky position for you and for the other coders who are looking at the script. It is very rare for folk to progam in an identical way so it might look good to one person but to someone else it seems illogical and wrong.

If it's really a mess, it rarely has to do with individual style. A mess is a mess. I know not everyone was being forgiving,