Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

86%

+11 −0

Meta What is a minimal, reproducible example?

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 enoug...

posted 3y ago by klutt‭ · edited 2y ago by klutt‭

Answer

#7: Post edited by

klutt‭ · 2022-02-11T06:50:04Z (over 2 years ago)

Copy Link

Raw

Markdown

# 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. 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.

# 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.

#6: Post edited by

klutt‭ · 2022-02-11T06:48:24Z (over 2 years ago)

Copy Link

Raw

Markdown

# 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. 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 are in a language speaks.

# 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. 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.

#5: Post edited by

klutt‭ · 2022-02-09T13:31:24Z (over 2 years ago)

Copy Link

Raw

Markdown

# 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.
# 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?
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.
### 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. 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 are in a language speaks.

# 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. 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 are in a language speaks.

#4: Post edited by

klutt‭ · 2022-02-03T21:50:50Z (almost 3 years ago)

Copy Link

Raw

Markdown

~~### TL;DR~~
~~A MRE (minimal reproducible example) is simply the minimal code 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.~~
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.
~~### 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.~~
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.
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?
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.

# 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.
# 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?
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.
### 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. 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 are in a language speaks.

#3: Post edited by

klutt‭ · 2022-02-03T11:16:34Z (almost 3 years ago)

Copy Link

Raw

Markdown

### TL;DR
~~A minimal reproducible example is simply the minimal code 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.
~~Remove as much code as you can, but always make sure that it does reproduce the problem.~~
### About the concept
~~Firstly, creating a minimal reproducible example is an excellent debugging tool. So this is really something you always should do when you're having a problem.~~
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.
So for instance, let's say that you're having some problem with a piece of code that reads some data from a file, 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 reading the file.~~
2. The problem disappears. Good, now you know that you are doing something wrong when reading the file, and you can remove the code processing the data.

### TL;DR
A MRE (minimal reproducible example) is simply the minimal code 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.
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.
### 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.
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.
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?
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.

#2: Post edited by

klutt‭ · 2022-02-03T07:51:31Z (almost 3 years ago)

Copy Link

Raw

Markdown

~~A minimal reproducible example is simply the minimal code needed 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.
~~Remove as much code as you can, but always make sure that it does reproduce the problem.~~

### TL;DR
A minimal reproducible example is simply the minimal code 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.
Remove as much code as you can, but always make sure that it does reproduce the problem.
### About the concept
Firstly, creating a minimal reproducible example is an excellent debugging tool. So this is really something you always should do when you're having a problem.
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.
So for instance, let's say that you're having some problem with a piece of code that reads some data from a file, 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 reading the file.
2. The problem disappears. Good, now you know that you are doing something wrong when reading the file, and you can remove the code processing the data.

#1: Initial revision by

klutt‭ · 2022-02-03T07:36:41Z (almost 3 years ago)

Copy Link

Raw

Markdown

A minimal reproducible example is simply the minimal code needed 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.

Remove as much code as you can, but always make sure that it does reproduce the problem.

Communities

Post History