VTK/MinimalExample: Difference between revisions

From KitwarePublic
< VTK
Jump to navigationJump to search
No edit summary
mNo edit summary
Line 3: Line 3:
Most importantly, you should provide a minimal, compilable, self-contained example of the problem.
Most importantly, you should provide a minimal, compilable, self-contained example of the problem.


* '''Minimal'''
==Minimal==
Do not include code that is not relevant to the problem. For example, if you are having a problem getting the neighbor of a cell that you click on (in the click event of an InteractorStyle), and getting to that point is not involved in the problem, then you should make the example specify the cell that you want to get the neighbor of programmatically, without involving any interaction or visualization.
Do not include code that is not relevant to the problem. For example, if you are having a problem getting the neighbor of a cell that you click on (in the click event of an InteractorStyle), and getting to that point is not involved in the problem, then you should make the example specify the cell that you want to get the neighbor of programmatically, without involving any interaction or visualization.


* '''Compilable'''
==Compilable==


Do not send code like this:
Do not send code like this:
Line 32: Line 32:
</source>
</source>


* '''Self-contained'''
==Self-contained==
Unless the problem is "I am having trouble reading this file", do not include external files in your examples. That is, rather than use a vtkXMLPolyDataReader, use a vtkSphereSource. Rather than read a text file with parameters, or accept command line parameters, hard code them into the example. Again, Copy+Paste+Compile is what makes life easy for the readers, and hence will get you an answer with higher probability.
Unless the problem is "I am having trouble reading this file", do not include external files in your examples. That is, rather than use a vtkXMLPolyDataReader, use a vtkSphereSource. Rather than read a text file with parameters, or accept command line parameters, hard code them into the example. Again, Copy+Paste+Compile is what makes life easy for the readers, and hence will get you an answer with higher probability.


* Other notes
==Other notes==


Formatting/indention:
Formatting/indention:

Revision as of 02:01, 8 September 2012

When asking questions on the mailing list, the goal must be to entice the readers to help you with your question. This means you should provide as much detail as you can about your situation. This includes things such as your operating system, compiler version, etc.

Most importantly, you should provide a minimal, compilable, self-contained example of the problem.

Minimal

Do not include code that is not relevant to the problem. For example, if you are having a problem getting the neighbor of a cell that you click on (in the click event of an InteractorStyle), and getting to that point is not involved in the problem, then you should make the example specify the cell that you want to get the neighbor of programmatically, without involving any interaction or visualization.

Compilable

Do not send code like this:

<source lang="cpp"> polydata = sphereSource->GetOutput(); </source>

instead, make sure that readers can copy+paste+compile:

<source lang="cpp">

  1. include <vtkPolyData.h>
  2. include <vtkSphereSource.h>
  3. include <vtkSmartPointer.h>

int main() {

 vtkSmartPointer<vtkSphereSource> sphereSource = vtkSmartPointer<vtkSphereSource>::New();
 sphereSource->Update();
 vtkPolyData* polydata;
 polydata = filter->GetOutput();
 return 0;

} </source>

Self-contained

Unless the problem is "I am having trouble reading this file", do not include external files in your examples. That is, rather than use a vtkXMLPolyDataReader, use a vtkSphereSource. Rather than read a text file with parameters, or accept command line parameters, hard code them into the example. Again, Copy+Paste+Compile is what makes life easy for the readers, and hence will get you an answer with higher probability.

Other notes

Formatting/indention:

Please recognize that the mailing list is a "plain text" environment. When you post code, realize that it may be read in an "80 character column" reader. Please ensure your tabs, indentation and line breaks look sensible. That is, rather than:

<source lang="cpp"> ...

                       writer->Write();
                       }else{
                               std::cout << "file exists." << std::endl;
                           ofstream fichier ("file.xyz",ios::out | ios::app);
                                       if(fichier)  // if the opening was successful
                                       {
                                                   cerr << " the opening was successful!" << endl;
                                       *//     now here i want the code that makes me save the "combined" in

"file.xyz" without overwrite the existing* ... </source>

post: <source lang="cpp"> ...

 writer->Write();
 }else{
 std::cout << "file exists." << std::endl;
 ofstream fichier ("file.xyz",ios::out | ios::app);
 if(fichier)  // if the opening was successful
 {
   cerr << " the opening was successful!" << endl;
   // now here i want the code that makes me save the "combined" in
   // "file.xyz" without overwrite the existing*

... </source>

The more readable you can make the example, the more likely you are to get a quick response (or a response at all!).