Register FAQ / Rules Forum Spy Search Today's Posts Mark Forums Read
Go Back   MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old Jul 3, 2013, 06:52 PM   #1
ArtOfWarfare
macrumors 601
 
ArtOfWarfare's Avatar
 
Join Date: Nov 2007
Send a message via Skype™ to ArtOfWarfare
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:

http://learnpythonthehardway.org/book/ex36.html

Some of his advice sounds downright bad, namely:

Quote:
  1. Every if-statement must have an else.
  2. If this else should never be run because it doesn't make sense, then you must use a die function in the else that prints out an error message and dies, just like we did in the last exercise. This will find many errors.
Obviously I'm no Python expert, having only started this book 60 hours ago or so, but since this is very wrong for every language that I do know quite well, it seems like it's probably very wrong in Python as well.

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:

Quote:
  1. Do not use a "debugger". A debugger is like doing a full-body scan on a sick person. You do not get any specific useful information, and you find a whole lot of information that doesn't help and is just confusing.
  2. The best way to debug a program is to use print to print out the values of variables at points in the program to see where they go wrong.
Um... no? Totally wrong? I don't actually have an IDE for Python yet (any suggestions?) but that sounds like a gross misuse of print to me. Shouldn't print be used only to log significant events in your program, not every little thing that happens? Shouldn't you use a debugger and breakpoints and stuff? (IDK, he hasn't brought up anything like this so far, but I imagine such features probably exist in some IDE somewhere.)

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.
ArtOfWarfare is online now   0 Reply With Quote
Old Jul 4, 2013, 01:53 AM   #2
Ap0ks
macrumors regular
 
Join Date: Aug 2008
Location: Cambridge, UK
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.
Ap0ks is offline   0 Reply With Quote
Old Jul 5, 2013, 12:53 AM   #3
ytk
macrumors regular
 
Join Date: Jul 2010
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.
ytk is offline   0 Reply With Quote
Old Jul 5, 2013, 01:14 AM   #4
subsonix
macrumors 68030
 
Join Date: Feb 2008
Quote:
Originally Posted by ytk View Post
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.
The Perl die pattern was what I thought of as well. But why not test for the failure case directly in the if statement? If you get past that, there is no need for an else.
subsonix is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 12:32 PM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC