# Background

I've been meaning to ask this for a while, and this meta question prompted me to finally write something. I've read the answers to that question and the ones to which it links, and the impression I get is that, other than the hard limit of 65K characters, there's nothing wrong with longer questions per se.

At the time of this writing, I have asked seven questions, three of which have received no answers:

# Sanity check

I compared my questions against Simon's Guide for posting a good question:

The binary tree and bounding box questions both do exactly what they're supposed to do, so they're definitely on-topic. For the workflow question, I went back and forth between posting it on Stack Overflow and Code Review, and I'm still not quite sure where it belongs.

Motivation

The bounding box and workflow questions are both real problems that I've run into and would really appreciate insight on possible better solutions. The binary tree question was just a little project that I thought was kind of cool.

Usage code, example inputs and outputs

I think I had a pretty good number of example inputs and outputs in the binary tree question. I suppose I didn't have so many for the bounding box and workflow questions, though.

Description

Describe the details and your approach

Class/Method summary

I wrote a lot of description of my code and the reasoning behind it in each of these three questions. Probably way too much description, actually.

Don't assume that everyone knows what you are talking about

I'd like to think that I did a good job on this one, but I think someone else would really have to be the judge of that.

Does your code do anything useful or interesting?

The binary tree printer is kind of cool, I guess. I think the bounding box tracker illustrates a more general question of how to extend data structures and handle coordinated (nonconcurrent) change in a functional way. The workflow question is something that I would consider to be essential for programming in Clojure (for me, anyway), but again, someone else would have to be the judge of that.

Screenshots

Doesn't apply; the only question that involves a GUI is the workflow one, and the GUI is not the focus there.

Take your time, don't be lazy

All the specific questions I have about each of these pieces of code are things that I cannot figure out how to solve, not things that I would solve myself but am too lazy to do so.

Possible things you cannot use

Doesn't apply; if there's already a way to solve any of the problems I've posed, I would love to hear about it.

# What should I do?

There are a few possibilities I can imagine that would explain the lack of answers:

• My questions are in a relatively unpopular tag
• My questions have too much code
• My questions have too much description
• My questions are uninteresting

I simply don't know which of these are correct, if any. What's particularly interesting to me is the fact that, while the binary tree and workflow questions both have zero upvotes, the bounding box question has five. What's special about that question? Is it the tags? The giant headers that I used to break it up into four sections? The specific problem that I'm trying to solve?

In addition, my four other questions, which are all considerably shorter than these three, have each received at least one answer. To me, that says that the problem with my longer questions is almost certainly the fact that they're, well, long.

• What are the zombie ratings of your questions?
– Mast Mod
May 7 '16 at 14:44
• @Mast I guess you could call the binary tree printer a project, so that would be 3 zombies plus 1 more for using a less popular language, correct? The bounding box one is really just a type definition, so that would just be 1 zombie for using Clojure. The workflow question isn't really a project either; it's more of an example, and a fairly small one at that, so I'd say that would just be 1 zombie as well. May 7 '16 at 14:50
• Probably way too much description, actually. - that. The code itself is reasonable, but the length of the text makes the posts seem much more daunting than it is. You could try trimming the text and putting up a bounty =) May 7 '16 at 15:05
• @Mat'sMug I tend to be a long-winded writer, I think. In cases like this, I find it very difficult to find things to cut out. If you could give some specific examples of stuff that could be removed from my questions so I can have a better idea of what to focus on in the future, that would be amazing. :) May 7 '16 at 15:09
• This question is too long. May 11 '16 at 17:54
• @oscilatingcretin Hmm, yes. May 11 '16 at 18:50
• Tis' sad you still have no answers :( May 19 '16 at 2:12

Your code is average, maybe a bit on the large size, nothing that I'd not answer.

Your problem is I see a wall with code, text, some lists, more text, more code, more text, more code and then 'how can I improve my code'. I instinctively just go "No." press back and don't think twice about it. Someone else can answer, I'm not going near that.

It's harsh I know.

Honestly I'd much rather your question be a complete code block, it'd simply cause the following 'production line' "copy -> paste -> run -> improve -> test -> answer". But I have to take a lot of effort to just get to run, there's now tons of copy's and pastes. And honestly I've done that 'production line' more than once and it still helps people as you can read their code.

If you want to still write a massive amount of description that's fine, I'll ignore it. But if you do use fn-name to highlight your function names, keep your description and code separate and let us lazy ones be lazy.

Currently you have the text:

Finally, since I'm going to be combining sparse strings in addition to just creating and printing them, I'll need a function to shift the reference point of an existing sparse string:

This broke the code block, a no-no. Which could be.

Finally, in shift, since I'm going to be combining sparse strings in addition to just creating and printing them, I'll need a function to shift the reference point of an existing sparse string.

It has the entire context in the text, and won't break the code block! I can then read the code after reading your description, or just your code. And caters to everyone.

• Excellent answer, thank you. So you're saying that description is fine, but it should all come before or after the code, rather than mixing the code and the description together throughout the question? May 7 '16 at 15:37
• @Elogent 100% don't break the code block, let me be lazy! I'd go for a 'you don't need to know the code' description at the top, like you did, and the 'you need to have the code' description after the code, not throughout it.
– Peilonrayz Mod
May 7 '16 at 15:39
• @Elogent Just to note, I'm not saying don't write your descriptions, please keep them, all of them. The input/output code blocks should also be separate from the code one. And from reading the entire of "Printing binary trees", it definitely shows that you put an admirable amount of effort into your question.
– Peilonrayz Mod
May 7 '16 at 16:39
• So you're saying you don't agree with Mat's Mug and Mast that I should be writing less description? Interesting; I'd still like to see some specific examples from @Mat'sMug on things to remove from my descriptions, though. May 7 '16 at 16:53
• @Elogent I guess it's a subjective thing.. not sure what I'd remove either, but I definitely agree with this answer. May 7 '16 at 16:57
• @Elogent I don't think what I've said conflicts with what they said, I agree with both of them (+1 on both those things). I agree your description could do with shortening, so I'd format it like I said above, but if you wish to write lots, and boy do I suffer from that at times, you should.
– Peilonrayz Mod
May 7 '16 at 17:08
• @JoeWallis Fair enough. :) Do you have any thoughts on why (before I posted this question) the bounding box question was the only one of the three that had upvotes? Or was it just the way the dice fell? May 7 '16 at 18:00
• @Elogent I honestly don't know, I don't know clojore. So I'll just say Tim Post lost his keys again, aka it's just the way the dice fell.
– Peilonrayz Mod
May 7 '16 at 18:07
• @JoeWallis Makes sense, thanks. I'll go back and edit my questions using your suggestions as soon as I get the chance. Sorry about the profuse upvoting of comments; I just really appreciate all the extremely helpful advice everyone's given me on this. Thanks guys! :) May 7 '16 at 18:15
• @Elogent And that is why I joined this community! :) When you edit the tree one, ping me and I'll put a bounty on it the next chance I get!
– Peilonrayz Mod
May 7 '16 at 18:24
• @JoeWallis Done! If you can think of other improvements I could make to the question, please let me know! :) May 8 '16 at 3:34
• @Elogent I read your question before and didn't really know what you were on about, but I just read it again, and I want to learn closure to figure out what you've done now! It's funny how your description is significantly more than your code tho. But bounty set.
– Peilonrayz Mod
May 8 '16 at 3:51
• @JoeWallis Thank you so much! I would absolutely recommend learning Clojure when you get the chance. I started with Clojure for the Brave and True, which I found to be a really great book, especially if you haven't really done functional programming before. :) May 8 '16 at 4:16

I don't think that there is anything wrong with your question length. If anything, I would guess that the fact that your questions are written in Clojure is a bigger factor in explaining why they haven't been answered. If you have asked 6 questions and gotten 3 of them answered, that's not too bad.

Code Review is a community-run website to improve programming skills through peer review. That means that the answers have to come from the community. You have posted 7 questions but only 2 answers. I'm not saying that posting answers to others' questions will lead to your own questions getting answered, but please keep in mind that you are also part of the community that we are trying to build. Every little contribution helps!

• Believe me, I would love to help as many people with Clojure as I can, but as you pointed out, there just isn't a lot of activity in the Clojure tag. The two unanswered questions that were posted in 2016 and weren't written by me are about a Project Euler problem that I haven't solved yet and don't want to spoil for myself. Are you saying I should go back and answer older questions, or look in other tags, or write more answers to already answered questions, or something else? May 8 '16 at 2:58

There are a couple of subjective reasons which may or may not impact the lack of answers.

You seem to be quite focussed on . Some of the reviewers, including myself, are not interested in such questions. If we take the first question you linked to as an example:

And that's it! Very long, I know. Is there a way to make it shorter? Cleaner? Faster? Better in any way? The one thing I'm most interested in is how to break down some of those longer functions into shorter, simpler ones.

You emphasize on code length and it sounds like you don't really know what else should get priority after that. Shortening functions is good, but shortening functions usually leads to a small amount of overhead which could increase the total length of your code. In my opinion (and many others with me), this potential overhead is worth it. Comparing functions by their Lines of Code is over-hyped and dangerous. Readability and performance are always more important. Conciseness can be a part of readability, but don't overdo it.

Your tags aren't popular. Not much to do about that. has 165 questions, that's not much.

Your third question gives a lot of context (too much, actually) and ends with questions which could be misinterpreted as stand-alone Stack Overflow questions.

### Conclusion

Your questions are on-topic, but could use a more structured approach. Tell us what problem the code solves and what your primary concerns with the solution are. Don't overdo the amount of information you give.

• You're absolutely right about code length. The reason I mentioned that specifically in the binary tree question is that, before I actually wrote the code, I for some reason expected the final product to be considerably shorter than it ended up being, and I was disappointed when my solution turned out to be so long and complex. However, in my other two questions, I didn't even mention code length. Do you have any comments about the bounding box question? And could you elaborate more on what you mean by "could be misinterpreted as stand-alone Stack Overflow questions"? May 7 '16 at 15:15
• As far as the remark about SO questions goes, they are specific 'how should I do X' questions. That's SO territory and isn't necessarily best asked on CR.
– Mast Mod
May 7 '16 at 15:32
• OK, makes sense. So you're saying that the workflow question would have been better as three separate Stack Overflow questions, rather than one Code Review question? May 7 '16 at 15:33
• It very well could be.
– Mast Mod
May 7 '16 at 16:18

It seems like you're looking for a review... a Code Question Review!

I looked over your unanswered questions, and they seem to be very long (as you have noted). Actually, the code is fine, but you just have a lot of words in the question. (Ironically enough, it applies to this very meta question, too.)

Length in itself isn't bad, but it creates a reliance on the structure of the content. When I read your questions, I have a very hard time trying to piece together the parts. People's attention only lasts so long before they give up and move on, so it's important to hook people with your opening.

I think that https://codegolf.stackexchange.com/ has a number of questions with great opening hooks. These questions seem to always follow the same format, so they are very easy to put together and read. Which leads to my next point.

You also don't seem to be organizing your content very well, and you are including a number of irrelevant details. For example, you seem to be writing lengthy summaries of what the code does. I'm not sure if this is necessary to have if your code is well commented. I think that a brief summary of how it works may be more effective.

I think that you are already including all of the things you need for a great post, you just need to assemble them properly.

I suggest that you use a template to help you organize your questions. Maybe something like this:

<What the code does>
<What language/technology you used>
<Why you wrote it, briefly>
<How it works, briefly>

<How to use the program>
<Sample IO or pictures, if applicable>

<What you want from review>

<Teh codez, ready to copy paste>


Now, I have grouped some lines together because I can imagine them appearing in any order without it mattering too much. It's really more of a guideline, not something that needs to be followed exactly.

Taking this question, I tried my best to model a short example of how you might restructure something to follow the template I made. It's probably somewhat inaccurate (I am using placeholders in several places, too), because I am completely unfamiliar with Clojure, but I hope it will provide you with an idea of how the template would work.

I answered [a question] on SO, and that made me realize how hard printing binary trees is. I decided that I wanted to find a more elegant solution, so I wrote a program in Clojure to do that.

My program takes a "sparse string" and plants the corresponding binary tree. Basically, it recursively generates each subtree, then puts them together so they can be outputted.

• Each node is separated by spaces, etc, etc, etc.

In order to test my program, I generate the sparse strings with this code: <code>

For example, when <sparse string> is fed to my program, the output is <binary tree>.

I'd really like get some detailed feedback about a few things:

• Is my code elegant?
• Do you think my trees are cool?

Here is my code: <teh codez>

(Side note: code formatting in a block quote is too hard to see on meta.)

• This is a question review of revision 4 of "printing binary trees", right? (It may be worth mentioning as the ones above are of rev2)
– Peilonrayz Mod
May 8 '16 at 18:15
• What @JoeWallis said. I honestly don't see much difference between the current version of that question and the structure you propose; perhaps the only thing I might change would be to just remove the "Implementation notes" section entirely. After I consolidated the code and description into separate places, I realized that all the previously intermingled description isn't nearly as useful as I thought it was. May 8 '16 at 18:30