TL;DR

A MRE (minimal reproducible example) is simply the minimal code and information needed for someone who is reading your question to reproduce the problem you are having.

It needs to be enough code to actually reproduce the problem. Don't omit code based on a guess where the problem is. And don't leave out information that's needed. Most importantly, tell us expected and actual behavior. Don't just tell us that "It does not work" or "The error is broken".

Remove as much code as you can, but always make sure that it does reproduce the problem. Make sure that the code actually demonstrates the problem. Don't just assume that.

There are always exceptions to ideal situations, but an ideal minimal reproducible example looks something like this:

I have this python code:

print("hello world".capitalize())

And it prints this:

Hello world

As you can see, it only capitalizes the first character. How do I make the whole string uppercase? I want this:

HELLO WORLD

It is a trivial example, but it fulfills the important things. I can take the code posted and paste it in a Python interpreter and get the same output as stated in the question. And then it's a clear explanation of how the actual output differs from the expected output with a clarifying example.

Do note that it's usually not enough that includes the problematic part. It also needs to demonstrate it. Instead of saying "The function foo() returns 42 instead of 88" it's better to say "print(foo()) prints 42 instead of 88". Sometimes the problem is in the printing. But even if it isn't, this provides a very quick way for us to verify your problem.

About the concept

Firstly, creating a MRE is an excellent debugging tool. So this is really something you always should do when you're having a problem. If you make a habit out of this, you will probably notice that you often will solve the problem in the process of creating the MRE.

Secondly, it helps isolating the real problem. Very often when people are posting questions without doing this, the problem is not where they think it is.

Thirdly, we who are spending our time to help you don't want to spend time on reading code we don't need. You will get help quicker and better if you help us helping you.

Examples of the process

Remove I/O if possible

So for instance, let's say that you're having some problem with a piece of code that reads some data from a file or from user input, process the data and then prints something based on this. Start by skipping reading data from the file and instead hard code the data directly in the code. This can lead to two things.

1. The problem persists. Good, now the code is much easier for us to try, and you can remove all code related to getting the data.

2. The problem disappears. Good, now you know that you are doing something wrong when reading the file or input, and you can remove the code processing the data.

In case (2) where the problem disappears when doing this and you have a problem with input, make sure that you include an example or two of your input.

Also, hard coded test cases makes it MUCH less tedious for us who want to help you. We certainly don't want to run your code and then type in 20 numbers manually to create an array. And we don't want to create input files unless necessary.

Remove unnecessary options

Another example. Say that you have a switch statement with 10 different cases you're having problems with. Are you sure that all 10 cases are necessary to demonstrate your problem? Maybe it's enough with just 2 or 3?

Remove dead code

Don't ever tell us to ignore something in your post. If it should be ignored, it should not even be there. So remove all dead code. However, sometimes it could be an idea to keep code you have commented away, to show your thought process, or to show something like "This code crashes if I uncomment this line." But be conservative with this.

Indent the code properly and clean it up

This is not really necessary to create an MRE, but code other should read should ALWAYS be nicely indented. It does help readability, and readability is one of the purposes of creating a MRE. Also, spend some time cleaning it up in general. Make sure variables have good names as such. English is preferred, even if not strictly mandatory. But it's much easier to quickly understand what the code does if the identifiers and printouts are in a language we understand.

posted almost 3 years ago

CC BY-SA 4.0

3y ago

klutt‭

1273 reputation 17 12 162 52