Is all code really code? One question from an interview
-
Andy,
Of course one of the best answer would be to add print statements, but in reality no better of an answer than checking your test data or verifying your program logic. However, All three things are necessary to be done to find the problem. So, your logic of your answer, IS NOT so correct. Print statements are useless, unless you know what your data inputs are, and are you really sure they are what you think and prints statements on the data inputs may not be truley showing you the real data. You can't verify the results of a print statement without knowing the logic, and manually computing it, etc. That is a few more steps/slower than doing a visual inspection/review of the code logic. Print Statements will Never show you the error, you still have to look at the code.
Verifying a few data elements First is quicker than reviewing 200 lines of code and the same is true of a visual inspection of logic versus playing with print statements and breaking out a calculator walking through the code to verify the results.
However, this is my kicker,
I would not hesitate to fire you for consistently writing procedures with 200 lines of code because it is code like that, that are signs of poor programming skills and typically inefficient causing performance problems due to long execution or contention/conflicts.
All code should be modular, small/efficient chunks of code results in less locking issues, easier to maintain and understand. It is one of the first thing taught in ALL languages.
-
A lot of interesting comments.
I have no problem with asking this type of question as it will give you insight into the approach to problem solving. That is, do they start with the bigger picture, asking more about the periphery than the problem or do the start in the centre and start ripping apart the code.
Any answer is a good answer as it tells you something about the person. Do they umm and ahh and hesitate nervously or give you a quick confident answer, albeit not your preferred one.
I am, and still, a developer at heart, I like to get straight into the guts of the problem to solve it. But this is still done in a methodical manner and in the case of TSQL I process parts of the query in sections to check results, this will show up any problem with code or data. I can understand people when they check data first but it may not resolve the problem any faster as will checking code first, that is one of the catch-22, chicken and egg, double edged sword things. What is important is how someone approached debugging (if done at all!).
Many, many moons ago (too many too mention) I came across the perfect debugger, MAUD. What you do is find the best liked person in your workplace, make a lifesize cardboard cut out of that person and stand it in the corner. When you have a problem, you get MAUD to stand next to you and you explain the problem and any diagnostics to MAUD. By the time you finished, your guaranteed to have found the problem and the answer and without consuming other precious resource.
Far away is close at hand in the images of elsewhere.
Anon. -
MAUD is pretty funny. I've heard it referred to as ducking as well, you explain to another person who nods their head continuously like a duck, at some point you usually apply your hand to your forehead as you solve your own problem.
-
MAUD? Ducking? Okay, you both made me giggle. I love it! Does MAUD stand for anything?
All the best,
DaleAuthor: An Introduction to SQL Server 2005 Management Studio
-
To be honest, I don't know. I think it is just a name that was chosen, maybe I should have typed it as Maud. Just seemed appropriate, no offence to any Maud's out there.
Far away is close at hand in the images of elsewhere.
Anon. -
Uh oh! You might have started something!
How 'bout "Mother of All Understanding Debuggers"? Or is that too nice?
All the best,
DaleAuthor: An Introduction to SQL Server 2005 Management Studio
-
I normally don’t cross post, but I didn’t want my question to get lost in the middle of this thread, and the people who have posted to this thread seem to be very knowledgeable about the subject. Please take a peek at my question and see if you can give me some assistance.
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=23&messageid=127243
Many thanks!
Jon
-
I thought this was really funny. I was listening to Mix 105.1 radio this morning and they brought up this trivia question. I thought I would pass it along:
Question: Our question today is about the origins of a computing term. Where did the term "debugging" come from?
Answer: At 3:45 pm on September 9th, 1945, while testing a failure on the Mark II Aiken Relay Calculator at Harvard University, operators found a moth trapped in the relay. It was removed and sticky-taped to the log entry "First actual case of bug being found". It was from this incident that we get the term "debugged", although the concepts of a "bug" or some sort of defect afflicting machinery dates back to the early days of telegraphy.
-
I somewhat disagree with the author's conclusions. IMHO, there are a number of assumptions built in to the question, as stated. The main one is that "the output is not 'as expected' ". I would suggest to the JP that (s)he investigate the expectations first, considering, for example, boundary cases in particular, without looking at the written code at all.
Once sure of what _should_ occur, one should return to the code (preferably after some break, such as lunch or day-end, as that normally clarifies the mind !) and make oneself certain that the code is, indeed, doing what one expects in the very small number of cases noted above.
Only then should one have approached the SP. At this point I would suggest using a debugger or print statements. I would suggest firstly using prints at input and output points, to gain information on the areas where the code fails. After that, refine one's investigation by binary reduction and tracing, either with print or a debugger.
BTW, many congratulations to MS for their excellent job in documenting their T-SQL Debugger. Guessing that it comes in the QA (no mention of it in the EM, as there isn't any help for the EM !),I looked up "Debug", and found a little info on the "Debugging Window", but nothing on how to open it ! Then I tried "Debug Procedure" - a phrase that cropped up a couple of times - and found a topic "Using Transact-SQL Debugger", a truly wonderful topic, but again, without any hint of hw to start it !
Purely by chance, now that I knew that it existed, I started right-clicking everything in sight, and finally right-clicked a stred procedure and looked all the way down at the bottom of the list of options !
For this (amongst so many others) I award MS the Arthur Dent Prize for Extremely Pointless Obfuscation. The trophy is a wooden plinth with a bronze forearm and hand (dressed in the sleeve of a rather tatty dressing gown) grasping an empty tea-cup.
-
With the wide variety of answers in this discussion, I'm surprised no one has mentioned an alternative to the debugger which should work even if the developers are locked out of the debugger...
How about taking the code from the stored procedure and turning it into a query, then running the "query" step by step; validating the results as you go.
I've also seen a couple of comments regarding digging into the "expected results" and would like to add that finding out "How the expected results are incorrect" is a very important pre-step to debugging. It not only allows you to concentrate your results on a smaller portion of the SQL code for debugging purposes; it also gives you a chance to challenge the verification query. I have found some situations where the query that was being used to "validate" the results of a stored procedure were somehow in error. (For instance, an extra set of business logic the "validator" wasn't aware of or faulty join logic in the validation query)
I enjoyed reading thru everyone's responses... excellent discussion!
Thanks,
Jeff M. Belina
Sr. Database Developer/DBA -
I've never been successful at getting the debugger to work. So, I just use the old tried and true print statement method. Of course, I never make mistakes, so I don't ever have to debug my procs...
I turn the stored procedure into a query in QA to debug it, then paste the code back into the procedure, and verify that it still works.
So long, and thanks for all the fish,
Russell Shilling, MCDBA, MCSA 2K3, MCSE 2K3
-
I'm fairly new to SQL Server, but not new to SQL. Didn't know about the debugger before, not impressed with it now. If it worked, I'd be more impressed with it.
I get: SP debugging may not work properly if you log on as 'Local System account' while SQL Server is configured to run as a service.
You can open Event Viwer(sic) to see details.
Do you wish to continue?
My choices are Yes/No/Cancel. Not exactly sure what the difference between No/Cancel are. I picked Yes.
It immediately ran to the end of the sproc. I can put in breakpoints, I can run the code again which ignores the breakpoints, I can remove all breakpoints. I can't "step-into" or any other of the options available.
Me, I'm used to taking the sproc apart, running the code in pieces and seeing if I get the expected results for each piece. MAUD sounds great, I've used the "duck" approach myself in the past. I've also been the duck on occasion.
To me, code is code. Years ago, I knew nothing about C, a co-worker asked me why his C code wasn't compiling. I scanned the code, asked why this line didn't have a ';', why he stopped indenting without terminating the block of code (The reason why the compiler went BLAH.), and a couple more items. I didn't find everything, but I at least got the compiler to start telling him what he did wrong.
I'm an old dog. When I first started coding, the debugger was a code dump. Not used to applications that actually stop and show me what's going on at this point in time, but I don't mind using that kind of tool at all. My only requirement is that the tool works.
Viewing 12 posts - 31 through 41 (of 41 total)
You must be logged in to reply to this topic. Login to reply