|Jul 3, 2013, 06:52 PM||#1|
Zed Shaw's Debugging Tips in Learn Python the Hard Way
I thouroughly enjoyed Zed Shaw's Learn C The Hard Way so when it came time for me to learn Python yesterday, I turned to his Learn Python the hard way, but I was shocked at the contents of chapter 36, which is on debugging.
Here's a link to the chapter:
Some of his advice sounds downright bad, namely:
For example, you have a function that can return early if a condition is met. That if doesn't need an else, but it shouldn't die either. Alternatively, maybe you have a function that contains some initialization code that needs to be run if a variable hasn't been properly initialized yet (that pattern is all over Obj-C, and I've seen in in many other languages too,) - and then it needs to do stuff with that variable once it's initialized. That initialization check doesn't need an else, and it shouldn't die if the condition isn't met.
Later in the same chapter he says:
Am I wrong in thinking the author's tips here aren't just useless, but harming naive novices who will now refuse to learn to use a debugger and will insist on having debug statements all over their code?
Battery Status - On the Mac App Store
The only app that'll estimate when your wireless devices will need their batteries changed.
Including the ones paired with other Macs on your network.
|Jul 4, 2013, 01:53 AM||#2|
If it's a small program and you aren't using an IDE (or you may not have much knowledge in how best to use a debugger) then using prints is a great way to find issues. You can easily compare what the program is printing to what you expect it to be printing and if they don't match then you know which section of code contains a bug.
As for the else statements it's not something I've ever done religiously but I can see where he is coming from. It will help you find conditional statements that aren't working correctly, if your application dies and logs a message you know that you have a faulty if statement in your code or something the user is doing hasn't been accounted for in code.
|Jul 5, 2013, 12:53 AM||#3|
The if/else thing makes no sense. If the “else” should never be run, then that means the “if” should always be run. And if the “if” should always be run, why bother putting it in at all?
The only time I can see this making sense is when you want to actually raise a fatal error because you believe the test might fail sometimes—e.g. the Perl “open or die” pattern.
As for the print debugging, it actually comes in handy sometimes. Especially if you're writing a short program, it's easier than breaking out the debugger, and often helps you get a handle on exactly what the internal state of the program is. For example, Ruby has a nice function that's simply called “p” which prints out any object passed to it, along with things like class information, instance variables, and so on. It's a great way to at least get your bearings if you're totally confused as to just what the heck is going on. So yeah, I wouldn't say to never use the debugger, but there's some benefit to using print statements for debugging purposes.
Last edited by ytk; Jul 5, 2013 at 01:02 AM.
|Jul 5, 2013, 01:14 AM||#4|
|Thread Tools||Search this Thread|
|thread||Thread Starter||Forum||Replies||Last Post|
|how hard is it to learn OpenGL ES||thekev||iPhone/iPad Programming||17||Feb 22, 2014 05:37 PM|
|Learn these top beauty tips and secrets, become a confident person||Gyonen||iPhone and iPod touch Apps||0||Jan 4, 2013 12:21 AM|
|iMac Hard Disk issue, any tips?||VTI1031||Mac Basics and Help||3||Nov 14, 2012 07:13 AM|
|Was English hard for you to learn?||wordoflife||Community Discussion||55||Jul 26, 2012 07:34 AM|
All times are GMT -5. The time now is 08:00 AM.