Clean code? any programs or people for $?

Karatancheva

Hi there!

I've written a program (online room booking system) for my college as part of my A Level project.

In my haste to finish it, I found I was programming in chunks with no identation or any logical presentation.

I'll lose marks fro this, does anyone know of a program that will lay out PHP syntax nicely? Failing this, is anyone willing to clean my code (JUST the layout - not much) for $25? (10 files of which 1 is 700 lines, 1 is 400 and the rest are on average less than 100 with some of only 50.)

Thanks in advance for any responses.

thorpe

is anyone willing to clean my code (JUST the layout - not much) for $25?

do it yourself you lazy sod!. jk :-)

i believe an ide like zendstudio will do it for you. do a google, maybe theres a demo available for download.

Roger_Ramjet

UltraEdit will auto-indent, colour-code and highlight syntax errors as you type. It's only $30, or was, and will last you a lifetime.

PS: there are very good reason why your teachers insist on well-structured code and why they dock marks when you don't produce it. So don't be such a dumb-ass, do it right the first time and you won't have to go back and do it right the second time.

jc94062

10 files of which 1 is 700 lines, 1 is 400 and the rest are on average less than 100 with some of only 50.

700+400 + (100+50/2)*8 = < 2,000 lines.

Just give yourself an hour or so and you'll get it done easily.

I'd suggest

Stage 1: Indent it all, use either

if () {
}

or if ()
{
}

without mixing and matching!
I prefer #2 for code readability (though increases the lines somewhat and can be annoying when limited by not having a 2x42" plasma screens at 1600x1200 to code on lol) but (most?) people seem to prefer #1 and either will work.

Stage 2: Go through each piece and comment it out as needed. Just put it all in a logical order on how it runs.

Weedpacket

Job postings are not allowed in these forums (especially since what you're offering is to pay someone to help you cheat).

You'd lose marks for bad presentation because you were supposed to use good presentation while you were working - it makes development and later maintenance easier. Otherwise you might as well just have it all on one really long line because that would make for a smaller file.

Karatancheva

Well, it is a mess because the problem I was set was very difficult to solve - I had to jump right in to try different ways of approaching the problem. Writing clean code at this point was my least priority.

Thanks for the responses and link to ultra edit.

thorpe

Writing clean code at this point was my least priority

well, in all honesty, you need to always make this your #1 priority. clean code, meens easy upgrades, debugging and generaly a longer application lifespan.

there is no point in writting an application that solves a problem that was in your own words "very difficult to solve", if the application is no longer maintainable through poor coding practices.

Roger_Ramjet

Karatancheva wrote:
Well, it is a mess because the problem I was set was very difficult to solve - I had to jump right in to try different ways of approaching the problem. Writing clean code at this point was my least priority.

Thanks for the responses and link to ultra edit.

When you've been at this a while you'll learn that half the problem is your approach.

'I had to jump right in...' Well yes hacking around and prototyping to clarify your understanding is very usefull, but only to help you understand the problem. Then you have to stop and think about it. Writing live code is the LAST thing you do once you have designed the solution. Indeed, it real world production programming writing code is only 10% of the job, the first 40% is analysing the problem and designing the solution, and the last 50% is testing and documenting whast you've written.

Writing dirty code just makes it more difficult all along the way. Your logic is not clear, and so debugging is that much more difficult. Without a clear solution design, you are not certain of where you are at any stage of the process.

It is fundamental in any engineering field that big problems are best solved by breaking them down into small problems. You can compartmentalise the parts, solve one problem, test it and then move on to the next small problem. Changes in one area do not impact on everything else.

Weedpacket

Roger Ramjet wrote:
Well yes hacking around and prototyping to clarify your understanding is very usefull, but only to help you understand the problem. Then you have to stop and think about it. Writing live code is the LAST thing you do once you have designed the solution.

Oh, that's so true. I've been in projects that lasted two weeks, with hacks and experiments and trials all over the place as the problem domain is nailed down; but where none of the real code was written until the last day, after we were so thoroughly familiar with the problem we could have given lectures on it to the client.