11
\$\begingroup\$

Say I am learning a programming language through a tutorial. To demonstrate a concept the tutorial provides a program, that is, some working, runnable code (not Code Snippets). Then I encountered an exercise that goes like this:

Improve this code, add N functions to do other things. Modify some fields and functions to do other things.

If I want my own code reviewed, do I

  • Post the whole code and indicate in the comments what's mine and what's in the tutorial
  • Post only the code I actually wrote on my own, then site the source where the exercise came from. I guess this would be harder for reviewers because my classes/functions can call/refer other classes/functions I didn't write.

Or other ways?

I think This is relevant

If you didn't write it, and acknowledge it, and it's only, say, a single method in a 300-liner class that you're posting, you're forgiven.

But since some code are exercise solutions, it's very likely the tutorial code can still be bigger than the added code (133 lines in a 300-liner). Is that acceptable?

\$\endgroup\$
1
  • \$\begingroup\$ Just my opinion, but I would lean toward your first solution, because it would be easier to understand the code in it's entirety and ensure that it's not broken or stub code. \$\endgroup\$
    – RubberDuck
    Aug 10, 2015 at 12:18

2 Answers 2

14
\$\begingroup\$

In the past, I've leaned toward the first solution, for the reason that RubberDuck makes in his comment, however, having seen a few questions asked like this, now, I'm not so sure.

Consider Exhibit A and Exhibit B.

These are both questions that from some Stanford course intended to teach people . They're different questions from different users from the same assignment. And we really shouldn't be too surprised to see this same question repeated. There's even a good enough chance that you want to ask a similar question, I think.

The problem is that some will find issues the way the tutorial code is written and will want to review those parts. Having answered both of the questions I just linked, I can tell you that was the case for me. It was only easier to resist the second time, because I had already said "Oh yeah, we've been here before."

And the hard part of it is that as a reviewer, on the one hand, I think it's important to comment on things that the tutorial does wrong so that they can be improved upon, we can all understand why that code is wrong and how to write it better and move on.

But on the other hand, I don't want some review that I spent time writing and thinking about to be shoved aside by an asker who simply says "Well, I didn't write that part."

So, with that said, here's what I recommend...

If you are interested in potentially hearing comments about bits the tutorial code got wrong, then consider yourself the new maintainer of all of the code (and the author of just your code). Post it all. Make it clear what's yours and what isn't yours, but also make it clear that you're also interested in hearing feedback on the part that's not yours, as you'll be maintaining this code now and want to make the effort to improve it all (even the parts you didn't originally write).

OR

If you are not interested in hearing comments about the parts you didn't write and only want feedback on how well you did the task the tutorial put to you, then you need to take a different approach.

You could post the whole code before your changes in the block quotes markdown, and then post the code you inserted below. Ultimately, having the original context will be important in answering the question, so it's important to have it accessible.

\$\endgroup\$
3
  • \$\begingroup\$ You've convinced me that this is the right way to do it. \$\endgroup\$
    – RubberDuck
    Aug 10, 2015 at 12:32
  • \$\begingroup\$ Please see edit \$\endgroup\$ Aug 10, 2015 at 12:38
  • \$\begingroup\$ The question you point to is possibly outdated. It is enough for you to consider yourself a maintainer of the code. Would you consider yourself a maintainer of the code? Are you going to take feedback about it all and apply all of the feedback to all of the parts of the code? \$\endgroup\$
    – nhgrif
    Aug 10, 2015 at 12:43
2
\$\begingroup\$

I'll try to answer your statement point for point.

Improve this code, add N functions to do other things. Modify some fields and functions to do other things.

Improved code is written code. Let's consider every part you improved to be yours.

Improve this code, add N functions to do other things. Modify some fields and functions to do other things.

Added functions are new functions. New functions you wrote.

Improve this code, add N functions to do other things. Modify some fields and functions to do other things.

While this sounds awfully vague, it's about modification. Every line you modified is your line. Every class you modified is your class. So the real question you should ask is whether you have modified enough code to consider it yours.

If you look at your code line-for-line, it will never be original. There are only so many ways of printing data to standard output or multiply two variables. It has been done before and it will be done again.

As long as a significant portion (say, at least half, but it depends) of the code is modified by you, I'd consider it (in this context) as yours.

\$\endgroup\$
2
  • \$\begingroup\$ Please see edit \$\endgroup\$ Aug 10, 2015 at 12:39
  • \$\begingroup\$ @morbidCode If the important parts of the code are yours, it seems like enough. Just note what part is yours and what part isn't. If the important parts are still made by the original author, it gets difficult. Unless you consider the original code as a library of-course, since we don't usually review the libraries linked in code unless OP wrote it. As said, it depends. \$\endgroup\$
    – Mast Mod
    Aug 10, 2015 at 12:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .