Page 1 of 3

Wonderful code

Posted: Fri Jul 27, 2007 10:06 am
by Benjamin
I really don't like dealing with code that is so poorly written that:

1. It breaks when you fix undefined variables.
2. It "depends" on other things not to work in order to work.
3. It's secure.. by accident.
4. Indentation is opposite what it should be.
5. It makes you sick to look at.

Ugh. This is going to be a long day.

Posted: Fri Jul 27, 2007 10:18 am
by superdezign
I had a kid (who actually posted here looking for help once) who wanted help with a website, so I volunteered to help. I was going to assist him in rewriting the pages and the second I opened it up locally, there were notices and errors everywhere and not a single thing was displaying. Everything was random includes that all depended on a root directory, short tags were mixed in with long tags (so it was hard to notice), some associative array indexes where in quotes, some weren't (also hard to notice), and not a single variable was checked before use.

Naturally, as I wasn't being paid to do it, I gave up and told him he was on his own. It was just *too* messy. And don't get me started on the AJAX...

Posted: Fri Jul 27, 2007 10:20 am
by malcolmboston
haha i feel you astions :lol:

In a previous job i worked on a major web-site updating the PHP code to be more 'friendly' basically the entire codebase was built 5 - 6 years prior to me working there, no documentation even though the system used some of the most complex mathematical calculations ive ever seen and i had the mammoth task of updating it to not be using globals, class-based etc.

Needless to say i have never been more bored in my life, if this was what being a professional developer is all about then i would of left this career entirely.

fortunately for me i now work on another quite big site, completely my own code, i love it :D

other peoples code, especially old code can often be a chore to work with, but i guess thats due to developer skill, documentation etc.

Posted: Fri Jul 27, 2007 10:52 am
by MrPotatoes
or when your boss says "look at the function" in order to figure what is going on. i hate playing archaeologist just to fix problems. *ugh*

it should be well documented dammit

Posted: Fri Jul 27, 2007 10:58 am
by Benjamin
Well I got everything working in one bit of code by unsetting all the variables used in comparison operators lol.

Posted: Fri Jul 27, 2007 10:58 am
by superdezign
MrPotatoes wrote:or when your boss says "look at the function" in order to figure what is going on. i hate playing archaeologist just to fix problems. *ugh*

it should be well documented dammit
Hehe. It isn't until you have to deal with undocumented code that you realize the importance of documenting and commenting the source.

Posted: Fri Jul 27, 2007 11:34 am
by RobertGonzalez
I did something similar to superD... I agreed to do a simple application addition used to sort nav links coming from a SOAP call.

When I loaded the code on my machine it threw out 847 warnings. The SOAP call wasn't even being used as the initial soap call was cached by the original coder and turned into, get this, two multidimensional arrays that were ~38,000 lines and ~15,000 respectively. It also relied on register globals being on and it used long global array names in addition variable variable substitution on GET vars that were never validated.

The more I fixed the more things broke. I gave up on the project after the job got bigger with every repair I made. The scariest thing about this was this was being sold by a guy for $50 per. 8O Unbelievable.

Posted: Fri Jul 27, 2007 11:56 am
by Maugrim_The_Reaper
http://pear.php.net/package/PHP_Beautifier - may sometimes help to standardise code enough to be readable ;).

I've worked on some pretty ugly looking stuff too. I remember one example where a parser was built out of entire chunks of ereg pattern matching. I think once you come across something of that type, it's time to start pulling things apart and reworking the places you feel are particularly bad. These days PCRE gets the boot in favour of DOMDocument, for example, when parsing HTML - and the resulting code is usually miniscule compared to the original.

I have to say I've come across only 2 projects that I'd call "lost causes". Both were, as Everah encountered, being sold. It's probably not that remarkable though - if something works, people will pay somewhere for it.

Posted: Fri Jul 27, 2007 11:56 am
by MrPotatoes
superdezign wrote:
MrPotatoes wrote:or when your boss says "look at the function" in order to figure what is going on. i hate playing archaeologist just to fix problems. *ugh*

it should be well documented dammit
Hehe. It isn't until you have to deal with undocumented code that you realize the importance of documenting and commenting the source.
i normally do writeups. i always do a design document and test compilation (or dry runs with interpreted langauges). i comment the code as much as possible. when i remember. since most of the code i do is for myself i don't need crazy comments (i do anyways). then i get code like this. omg. i don't even know where a stupid ass "insert" sql statement is created and it's driving me crazy.

when i start my company i'm going to over test, over document, over comment and it's going to be fantastic. well, not at first but it will down the line when we have to find some wierd ass function/class/library and we know EXACTLY what is going on.

Posted: Fri Jul 27, 2007 12:16 pm
by TheMoose
If I'm doing code that other's will see/use, before I even code a portion, I comment what I want it to do. Then I'll actually code it, and comment it as necessary. If something changes or I need to fix it, I'll modify the earlier comment so that it reflects what it's actually doing.

If I'm coding for personal use, I hardly use comments unless it's a complex portion. I know what I want it to do, I know what it does when I come back to it months later (takes me a second, but I usually have good memory for that kind of stuff :P).

Posted: Fri Jul 27, 2007 12:48 pm
by Chris Corbyn
This is one of the worst things about doing freelance work where the client says "it's just a quick modification". You quote a price, sign the NDA, get your hands on the code, then start crying and lose out because whoever worked on the code before you just created a disaster. I'll stick to working for companies who produce their own code :)

Posted: Fri Jul 27, 2007 2:35 pm
by superdezign
TheMoose wrote:If I'm coding for personal use, I hardly use comments unless it's a complex portion. I know what I want it to do, I know what it does when I come back to it months later (takes me a second, but I usually have good memory for that kind of stuff :P).
Yeah, I'm the middle of a huge project right now and I have commented a total of 5 lines in the entire application. I plan to document every portion of it later since there are certain parts that aren't as self-explanatory as I'd like them to be, but when I'm programming, comments slow me down, and since I know I'll be refactoring, I know that I'll end up changing half of the comments as well.

Posted: Fri Jul 27, 2007 3:12 pm
by Chalks
I typically draw an entire outline of my applications on a piece of paper. With a pencil. By hand. :crazy:

Then I write the comments for each function, describing what it should do.

Then I code the whole thing.

Then I fix the comments again and comment each class file.


I know that's probably more steps than I need, but it helps me quite a bit to organize my thought process, and keep me focused.

Posted: Fri Jul 27, 2007 3:20 pm
by superdezign
Chalks wrote:I typically draw an entire outline of my applications on a piece of paper. With a pencil. By hand. :crazy:
Hehe, I use Macromedia Flash, a tablet, and Notepad.

Posted: Fri Jul 27, 2007 3:45 pm
by RobertGonzalez
I pseduo code, then put the actual code to it, then turn the pseudo code into PHPDoc blocks. Most of the time, not always.