The offence

There seem to be a significant amount of new people posting code that looks like this

a = (E^(-2 Abs[\[Gamma] - z Cos[\[Theta]]]^2) \!\(
\*UnderoverscriptBox[\(\[Sum]\), \(j = 0\), \(m\)]\(
\*UnderoverscriptBox[\(\[Sum]\), \(l = 0\), \(m\)]
\*FractionBox[\(1\), \(\(j!\)\ \(l!\)\)] Binomial[m, j]\ Binomial[m, l]\ 
\*SuperscriptBox[\(Conjugate[ z\ Sin[\[Theta]]\ Tan[\[Theta]]]\), \(j\)]\ 

Examples: 268606 268222 268172 267133

This String Based Input of Notebook Boxes, is normally created by using a palette or control keys. This form is interpreted by the Front-End without problems, but it is very hard to parse for humans. I call it unreadable.

The solution

A solution exists in the answer posted by @m_goldberg, back in 2015. The code that looks good is well-indented raw input form.

How to copy code from Mathematica so it looks good on this site


Choose Convert To > Raw InputForm from the Cell menu or from the contextual (right mouse click) menu. Then Copy & Paste

Previous discussion

This Q&A addresses what formats are acceptable

What kind of Input and Output Code Styles are acceptable in SE?

The answer by moderator @rm-rf calls for

  1. One should be able to copy-paste-evaluate the code block in Mathematica.
  2. The code block should be as noise-free as possible.
  3. Do not use fancy typesetting in your code.
  4. Try to use sane and reasonable indenting/formatting.
  5. Also, try to avoid the code block scrolling sideways.
  6. Keep the code and variables minimal and simple

Strictly speaking, the form I'm complaining about does comply with point 1, and may comply with 5 and 6, but definitely fails in points 2, 3 and 4.


Personally, I think it is NOT acceptable to share code that it's not human readable. Questions featuring such code should be corrected or closed.

Some people may disagree, and argue that such code can be interpreted directly by the Mathematica Kernel by pasting it into a Mathematica Notebook.

After the latter, I would offer the counterargument that before deciding to copy&paste code one needs to assess if the question deserves one's attention, and unreadable code doesn't allow that. The burden on the community is too high.

The question

The previous discussion defines the ideal formatting but doesn't conclude what to do with the questions that are not in an ideal form. I am not aware of any consensus on where is the threshold that divides acceptable forms from not acceptable.

I'm looking for a community consensus on whether this form of code is:

  1. Acceptable and should be answered without complaints.
  2. Unacceptable and questions of this style should be either edited or closed.
  3. Some other alternatives.

Is unreadable valid code acceptable in Mathematica Stack Exchange?

  • I was hoping people would offer answers with a variety of views. I will offer my own answer later so that we can vote and see where the consensus is.
    – rhermans
    May 30, 2022 at 16:08
  • I agree with Michael Siefert's answer. I don't see a good alternative, but if you have something to suggest, please post. I have other peeves that make me skip questions, which don't fit the focus of this question: the use of Subscript for variables (even though this comes from the docs for NDSolve); data links for which data = Import[url, type] does not work; no semicolons for data = {{...40 lines...}} or none at the ends of lines whose output is irrelevant; irrelevant *Plot or other solver commands.
    – Michael E2
    Jun 13, 2022 at 14:12

1 Answer 1


It seems to me that there are plenty of other reasons that a question could be perfectly answerable in principle, but which on the surface seem like they would take a lot of effort to decipher. Think of complicated NDSolve questions, for example. Moreover, the "human-readable" code that comes out of "Raw Input Form" is often not that readable either, particularly if it contains special characters.

But the outcome for such questions is just that they don't get answers. While this might be frustrating to the OP, I don't see how this greatly burdens anyone else. If I see a question with that sort of code, I would probably just close the tab and move on to the next question. I suppose it might reduce our rate of answered & accepted questions, but the time "wasted" on such questions doesn't seem like it would be all that much.

So while I don't think that such questions should be closed outright, I do think it would be helpful to encourage users to format their code correctly. In an ideal world we would have a pre-set option in the "First Questions" review queue saying something like

Your code isn't human-readable, which may reduce the number of people who are willing to examine it and answer your question. For instructions on how to include code in human-readable form, please follow the instructions on this page.

And if a good Samaritan wants to do the editing on the OP's behalf, then this should be encouraged as well.

  • 1
    My contention is not that they are non-answerable. The fact that these questions "could be perfectly answerable in principle" doesn't rule out that they can be off-topic or against policy.
    – rhermans
    May 30, 2022 at 10:43
  • 1
    Having unanswered questions is detrimental to the quality of the site. So when you say "But the outcome for such questions is just that they don't get answers" I disagree, the impact should not be dismissed, I do think that is a burden to the site. We are curating a Q&A catalogue, this is not a chat room.
    – rhermans
    May 30, 2022 at 10:45
  • I agree that it would be "helpful to encourage users to format their code correctly", the question is if that is enough or not. I say it is not enough.
    – rhermans
    May 30, 2022 at 10:46

You must log in to answer this question.

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