Re: Is it correct?

[tantarbobus]

Those are great questions... For an expert to ask (him|her)self. But what do they mean for someone that is just learning the language?

Here is my attempt to answer you questions from the POV of a novice:

1. Does it work correctly?

Um, I guess so. It seems to work? I cannot think of anything wrong with it; can you?

2. Do you understand it?

Somewhat. I think I understand it, maybe... Is there something I am missing?

3. Would anyone else understand it?

FIIK, a) I am not someone else, so how should I know what someone else thinks. b) I just learned this myself, and this is the way I learned it.

4. Will you understand it in a month's time?

I hope so.

5. Does it strike a good balance between terseness and verbosity?

FIIK!

This is like asking a 5 year old whether War and Peace strikes a good balance between terseness and verbosity. One must have sufficient mastery over the material to be able to judge.

6. Could you make changes to it without it being likely to break in unforeseen ways?

Good Question, how would I go about finding this out? What are the unforeseen ways?

7. Is it fast enough?

Is there a faster way to do it?

[wade]

I think the novice has to own the problem domain. He knows what problem he's trying to solve and the context in which it will be run. Given this, I'd respond as follows (if it were me who asked the original questions):

1. Does it work correctly?

Um, I guess so. It seems to work? I cannot think of anything wrong with it; can you?

I really think, here that you have to understand what you want the program to do. You need to understand the straight-down-the-center as well as the corner cases and, if you don't grok the code, at least have some tests you can run.

2. Do you understand it?

Somewhat. I think I understand it, maybe... Is there something I am missing?

This is, of course, subjective. If you don't get the basic principles, RTFM a bit and get some understanding -- you may have already done this, I don't know. Trace through the code by hand with some data and see if you think it does what you think it's supposed to. Add some 'print' statements to verify.

You may, depending on the original advice, come to a better understanding of side-effects and such at a later time. That's okay.

3. Would anyone else understand it?

FIIK, a) I am not someone else, so how should I know what someone else thinks. b) I just learned this myself, and this is the way I learned it.

4. Will you understand it in a month's time?

I hope so.

To address 3. and 4., together, I think these are really meant to ask: is the code readable? Are the variable names clear? Is the style easily read? Did you comment it well? I find that, when I'm learning something, I comment the holy snot out of it, explaining every detail as I think I understand it. If I learned something when I wrote the code, I make darned sure that someone else with the same level of experience I had when I started would understand the code.

5. Does it strike a good balance between terseness and verbosity?

FIIK!

This is like asking a 5 year old whether War and Peace strikes a good balance between terseness and verbosity. One must have sufficient mastery over the material to be able to judge.

No, I think this is more like asking a 12 year old whether the New York Times strikes a good balance between terseness and verbosity. It's a stretch but it's a good thing to consider. The answer may stray away for what an experienced programmer would say but that's okay.

6. Could you make changes to it without it being likely to break in unforeseen ways?

Good Question, how would I go about finding this out? What are the unforeseen ways?

Again with the RTFMing and the tracing of the code. This requires deeper understanding than do the other points. Give it a go, though. Look at side-effects. Try funkified data as an input. Always check the corner cases.

To figure out what the corner cases are, look at the expectation of the data. If the code is expecting numbers, try characters. How does the code respond to a gigantic amount of input or none at all?

7. Is it fast enough?

Is there a faster way to do it?

The answer is 'probably' but that's not the question you should be asking. Does the program run fast enough to fulfill your needs. Writing something faster than that often requires sacrificing readability and that would be a bad thing.

Update: fixed a typo

[tantarbobus]

This was in the context of a novice asking an expert, 'is this correct'. The point I was trying to make is that the novice may not be able to answer the questions with certainty but an expert can.

Have you ever met a student who walked out of an exam thinking s/he made an 'A' on an exam, only to find out that the actual grade was an 'F'? Sometimes everything can look correct and act correct (to the best of the knowledge of the novice), but is obviously incorrect when viewed at through the eyes of an expert.

And, at least from my point of view, for the novice it is much more helpful to know hat something is done correctly rather than spending many hours trying to make sure it is correct -- and still not being convinced. Self-study is infinitely harder when you do not have the answers to the problems to verify your understanding.

[GrandFather]

Actually I don't think in many cases even a guru, let alone a lowly expert, can give a definitive "Yes, that is correct" answer. Most of the questions are pretty open ended and depend a great deal on context, or even on context at a particular moment in time.

The questions are intended more to catalyze thought processes and an appropriate approach to considering what constitutes "correct" code. A large part of programming is art and there is no ultimate test for good art (the test of time is fairly definitive, but impractical for most purposes).

The time spent validating an answer should be a direct function of the importance that the answer is correct. If it doesn't matter at all then don't check it. If lives depend on it then you probably need to document the validation process, execute the process, then sign off on the result. Picking an appropriate level of validation is something for which there really is no litmus test - just like determining if a coding answer is "correct".

[Anonymous Monk]

Novice has to own the problem domain. Thank you, this is the smartest thing I heard on this site, for what, last several months, on this site.

[GrandFather]

wade has given an excellent reply already, but there are a couple of things I'd like to elaborate on.

2. Do you understand it? is in large part addressing cargo cult programming. Copying code is often a good way to get a job done and to learn along the way. It can also be a excellent way to pick up bad habits, lay nasty traps and generate incomprehensible code.

5. Does it strike a good balance between terseness and verbosity? I would expect to change over time in two ways:

As a project evolves cruft can generally be removed through refactoring. That most often reduces verbosity.

As programmers become more experienced they tend to learn programming styles that reduce verbosity.

The key element in this question however is the balance. Both extremes are bad. The balance may shift over time, but the question should prompt you to find a balance you are comfortable with.