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?

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

Wade --

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.

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.

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. Perl is environmentally friendly - it saves trees

A reply falls below the community's threshold of quality. You may see it by logging in.

I have to agree with tantarbobus on this. Some of the points raised are very difficult for a novice to evaluate. I think that 'does the code not do something it isn't meant to do' question is important as part of the 'does it work' question. (This is effectively asking the question, is the code within spec.) At a very simple level, most of us novices are monumentally relieved when we get a regexp to match at all. At last it works! However, how many perl novices then check whether that regexp matches what it oughtn't to? I guess this is where testing comes in and being able to effecitively test something is part general programming experience and part specific language experience. I haven't yet used the Test module yet because I feel I haven't written anything needing it yet. I also feel there is definitely a particular mindset to be adopted to be able to write terse but informative perl code . My code is verbose and I would love to be able to improve its terseness but I don't yet know how. Giving a novice along a few breadcrumbs along the trail is no bad thing. It is up to that individual to commit the time to learning but having guides along the way does help tremendously.

My first reaction was similar to yours and tantarbobus's. I wasn't thinking along the lines of "a novice would have trouble grading themselves on this scale" but rather "a novice would have no motivation to do so." It's not that I don't think the list is good - in fact, I think it is great - It's that one has to be burned by many of these things before they care about them. Does it work? I'm trying to think honestly how vigorously I tested for and checked edge/corner cases for correctness before my programs blew up in my face a few times. The answer: Not very much. Will I be able to read it later? Again, not something I cared about before I had to maintain my old code months and months later. Maybe I am on the stubborn side of the scale, but I think most novices, especially in programming, are more task driven than quality driven. Maybe the shift towards thinking about these things, writing quality code today to save yourself tomorrow, is one of the big gulfs between novice and expert :).

And if you contribute to a module: 8. Is it tested?



9. Is it documented?

If you can answer all of these questions with a definitive "yes" then you are either a grand-poobah Perl master or you are a liar of the double-nth degree (that assuming the coding problem isn't a trivial one). I think all of these questions have an answer on a sliding scale. However, as a novice I have to say that it's not all that important if all of these questions can be answered toward the "yes" direction right away. Except perhaps 3) and 4), which I regard in the same way - you should always write code as if you will forget everything you've done in a month. Because I usually do - darn that lack of experience! But I think verbosity should be encouraged in the beginning, and only after you're comfortable doing something should you try to strike the balance you mention. And not completely understanding code or knowing if it will work in all situations can lead to interesting lessons (unless you have to care about security of course) and revelations later on. I think most would agree, especially if they are doing funny things with dependencies that they don't know the intricate details of. The most important thing though from your post is that you should always be asking yourself these questions, usually implicitly, for every piece of code you write. That's the advice I would give to fellow novices.

I personally believe, dear GrandFather, that for once you got it wrong: wrt the title, that is. We bash newbies all the time for chosing uninformative ones. Now, I understand perfectly well that's not the same case, yours being a witty attempt at being... witty: and do not misunderstand me - you succeeded! Nevertheless, it turns out to be just as uninformative (and search unfriendly) as those other ones. Thus I suggest you rename -at the expense of some verbosity- it to something like "How to answer to 'is it correct?' kinda questions?" --

If you can't understand the incipit, then please check the IPB Campaign.

What about considering best practices and privacy and security concerns, etc.? I think your list falls a bit short.

Not such list would ever be "complete". It's largely a matter of finding a balance between terseness and verbosity influenced by considering what seem to be key elements. ;) Please, add your own item to the list. Perl is environmentally friendly - it saves trees

Hmm. Well, as a start I will throw out the SAGE Code of Ethics. It's for SysAdmins, but it's general enough that others on here can make use if it and I think it helps stess the importance of considering security and privacy concerns.

My general approach in any software context is to give maintainability at least as much importance as functional accuracy. In some cases, I'd go so far as to say that maintainability is more important than correctness! It's easier to fix a maintainable but bugged program than it is to do anything with an accidently obfuscated program that happens to to work for last week's requirements, but not this week's. All common sense caveats apply.

which is why items 2 - 6 address that issue. ;) Perl reduces Perl reduces RSI - it saves typing

I'd read the numbered points as an ordered list, implying that point one is the number one priority. Maybe I'm thinking too hard today, but read that way it's perfectly comprehensible, and ceratinly useful for reminding people that there's more to consider than whether anyone has complained about the results (yet). And I'd agree with each point in the list. However, I thought I'd contribute the slightly contentious view that sometimes accuracy is not the number one priority. Of course, if everyone agrees with that, then it's not so contentious. Bah - don't tell me I'm back in the mainstream again.