Link Details

My god this was awful..
From the foreach() section:
"One of my first projects, as a proper web developer (at an agency) ... [was] a nightmare getting the data out until I discovered foreach()"
"It’s my favourite loop by far… in fact it’s pretty much the only loop I ever use."

That entire section should pretty much bar you from any future coding in any language.

Yeah, this is pretty bad. Sorry imgiseverything person

Well, not everyone can be experts.

I think this is a good article for the beginner who's short on time and just need to get something up.

Hello everyone, thanks for the comments.

The article is written form the point of view of myself - not an expert coder but someone who has struggled to learn the backend side of programming whilst concentrating on the the HTML/CSS frontend. I was hoping people may enjoy the stories behind how the functions helped me as opposed to being concerned about how complex the functions actually were.

Thanks for posting this article. Don't be discouraged by people giving negative feedback because you aren't already as much of an expert as they might prefer. That is their problem, not yours.

IMO, there is a valuable place in the community for people to share thoughts and observations, even if they are only at the early stages of their lives as developers. Everybody starts somewhere, and that is altogether too easy for some experts to forget.

Rick

Thanks Rick - the 'against' votes are starting to stack up now though :)

Think positive and take those negative comments and learn from it :)
All of us started as beginners.

Nice to see you are learning something but I'd rather see some quality content on dzone

is foreach even a function?

exit() is about as much a legitimate debugging tool as the reverse cowgirl is a form of contraception.

Also, if you have data stored in an array and you have trouble accessing said data then you should probably never admit it in writing on your public blog. Actually, you should probably find a mentor--someone that doesn't know PHP.

The article is about learning PHP and the stories behind finding functions/constructs that have helped me to become a web developer.

Should I pretend that the programming knowledge I now possess was with me in the womb?

No, but perhaps you shouldn't broadcast to the world that you're under qualified for the job you now hold. You haven't yet become a web developer, sir. I'm not saying you'll never get there. I'm just saying you haven't yet earned that badge. Being a developer (as a contrast to a "programmer") is more than just knowing a programming language, it's about discipline and experience. You may have had some success in wringing the neck of PHP to do something you want it to do, but this article shows that you're not yet out of the neophyte stage. It's hard to give criticism without sounding hostile, but at the same time I cannot abide the advice you are giving to the next neophytes who pick up PHP. (I'm talking mostly about your use of exit() as a debugging strategy, here).

I'm not necessarily saying to abandon PHP. I'm saying that if you want to be a real developer, you need more dirt under your fingernails. Keep at it and learn a new language in the next few months and at least learn about some of the development disciplines out there. That's the best advice I can give any new programmer.

Thanks for your response eelmore - I'm not professing to be a expert web developer. Perhaps you would like to point me in the direction of some good quality debugging techniques - I'd love to learn more.

Effective debugging practices? Above all others, disciplined logging. There's not much else like an application log that makes effective use of log-thresholds (often called "log levels"). That will give you insight into your app at any stage of development--even after an app has been deployed and has not been touched for a long time. For example, you could temporarily tune your app to the highest level of log verbosity and go to work analyzing the information. After you're done, set the log threshold back down to normal. If you combined this with some sort of log aggregation and analysis tool (like Splunk), you could squeeze out even more information. Even for very small-scale inspection of running code like the scenarios you were describing would likely benefit from effective use of logging.

Another fantastic debugging discipline is the use of automated tests. This has a reputation for being strictly an "agile" practice, but I'm not sure I agree with that. The fundamental idea behind automated testing is to save you time. To use your example, arbitrarily and temporarily placing testing code like exit() or die() is a very direct way to get insight into your running code--however, once you gain that insight, you remove your temporary code and move on. Nothing long-term is gained by this and it is a very time-consuming practice. If your time and energy was focused instead on automated testing, the tests can run 1000 times in the same time it takes you to test it once by hand. Also, once a test has been written, it will always be there to continue testing what was once a problem area in your code.