Post length limit for Code Reviews questions and answers

For what it's worth, I agree on the other meta Q&A that the bug is a bug; the limit should count Markdown characters rather than rendered HTML, since that's what the user can actually directly interact with. The worst cases for this shouldn't blow the rendered HTML up to sizes that are problematic in 2026, anyway. (Trying to maximize this might make a good question for the Puzzles incubator!)

I don't want to focus too much on volunteer effort (some might perceive that this is the seed of a culture of resentment), but I agree with Olin Lathrop that an overly-long question is unlikely to be properly focused in a way that allows for useful feedback. Even for a Code Review section, where questions and answers are unlikely to be directly searchable and applicable for others (still a good learning resource for others, but not in a targeted way), the underlying problem really does need to be scoped down to something reasonable. It's normal for reviewed code to have multiple possible improvements, so that doesn't make them closable as what we currently call "too generic". However, I do think that the code under discussion should implement only a single feature (it might be a complete project that does a single, well-defined thing; or it might be an extract from something larger).

Of course, even on Code Review a question is more than just a code dump. Sometimes multiple code blocks will be necessary. But in these cases, the second code block should really not be a clone of the original code with a minor modification or anything like that; it should be a few lines to highlight an alternative, for example. And while there should be some framing text

Putting all of that together, it's really hard for me to imagine that more than 30,000 characters would ever really be necessary for a properly-scoped, constructive Code Review question. Right off the top, it's clear to me that the proposed question that ran into the bug could be shorter. The screenshot shows the code starting off with a large block comment, but the information there is almost entirely redundant in our format and should be removed. "OVERVIEW OF PROGRAM" adds nothing; the authorship is already established by the format; and so on.

posted about 2 months ago

CC BY-SA 4.0

Karl Knechtel‭

3154 reputation 42 71 391 103

The consensus in the answers so far is that 640 kiB ought to be enough for anyone any code review request longer than 30,000 characters is not “focused”—or not “properly scoped” or not “constructive”. I’ve been doing (volunteer, open-source) code reviews for the better part of a decade now, and my first thought on reading that was: “🤨 … interesting…”. My second thought was: “We need real data.”

So I did four quick, admittedly non-scientific checks. I started by considering, based on my experience, what kinds of projects newbie programmers have offered for review. I want to avoid singling out actual beginners as much as possible, but for the sake of evidential integrity, I will do it for just one case. All code is either C++ or C; C++ because that’s my domain of expertise, and C because (other than my own) there are no C++ code review requests (yet), but there are a few in C.

The first three projects I settled on were:

1. A “snake” game.
2. A command-line argument parsing library.
3. A cat implementation.

I have seen requests to review implementations of all three of these things multiple times over the years. Each one is a fairly simple project for beginners to tackle. In my opinion, all of them are pretty focused, and properly-scoped both for a beginner project, and for a review request thereof.

For the first two, I just went to GitHub and searched for relevant key words (“snake game” or “argparse”), narrowed down to C or C++. The one I picked was either the first one that popped up, or the first one that popped up where all the code was in a single file (or close enough to it).

For the third, I decided to be a bit silly, and chose the actual cat implementation from GNU Coreutis. Because, why not? I don’t think you can get any more focused or scope-limited than cat. And I can’t imagine the GNU implementation has all that much unnecessary cruft; I imagine it’s about as lean as it gets. It only has like 5 or so functions in it. If someone were trying to write a super-efficient cat implementation… I mean, would it not look kinda like this?

In each case, I just copy-pasted the file into my text editor and used the word-count feature to count the characters.

For the fourth project, I decided not to be hypothetical. I went to an actual code review request. Specifically, I went to my account on another site that does code reviews, chose the number-one-ranked question I had done a review for—which was for a C++ string class—and just copied the actual class code to get the character count. I did not include the tests, which were included in the review request. I also did not include any of the request text, or the benchmarking results that were also included. I counted JUST the code in the string class snippet. I don’t think anyone can plausibly argue that a single string class is neither focused, nor improperly scoped. And again, I repeat, this was a real code review request. (And a popular one, too!)

Here are the results:

Two of the projects came in at under 30k… though one by just barely. One was almost three times that.

And again, let me stress, these numbers are for JUST the code. No explanatory text, no usage demo, no questions. JUST the code.

Certainly there is a place for requesting reviews of a single function, or of small classes or tiny modules. But none of the projects above are “large” by any reasonable standard. And all of them are, in my opinion, quite narrowly focused, and pretty bog-standard for a beginner project that one might want to get reviewed for learning purposes.

So, yeah, I really don’t think 30k ought to be enough for anyone.

But then again…

So am I advocating for massively expanding the code review request question or answer size? No, not necessarily. I mean… I definitely think it should be larger. 30k is just way too small not only for a review request, but definitely for the actual review. Just imagine a review of just 10k of code, where a reviewer wants to go over (most of) the code line-by-line and explain issues or show alternatives; that just can’t be done in 30k.

So yes, 30k is definitely too small for code reviews in general.

However….

I don’t think it is either practical or smart to put the code being reviewed in the review request itself. That just blows up the size of the request post. When we put images in a post, we don’t put them directly in the post (expanded as base-64 or whatever); that would be silly. It seems similarly silly to put huge chunks of code—like whole source code files—directly in the post.

But of course, we can’t encourage simply linking to code to be reviewed either. That way lies madness; there is no way to ensure the code won’t be changed, or removed/replaced entirely, leaving the review request completely out of sync with the code. It’s also dangerous; requiring people to click off to who-knows-where to see the code under review could easily lead people to malicious sites, with all the nefarious consequences that come with.

What if, instead, we considered largish chunks of code to be link-able objects, rather like images? Not links, but objects that exist on the server, linked via a tag in the post Markdown, and displayed embedded in the post.

If the code is small enough, the user can just include it in a code block as before… but if it’s a larger chunk of code, or a chunk of code that involves multiple files, what if they could instead select an option when making the post to upload an entire directory tree? They could specify a file or whole directory on their local machine, or select an already compressed tarball/zipfile, or maybe give the URL to a git repository that could be cloned, and then the entire directory tree could be uploaded to the server (and compressed, obv).

When the post is displayed, it could just display the tree with the directory and file entries, only loading the actual files on demand if requested. In the long run, this may actually use less server resources than always putting all of the source code directly in the post. Source code compresses well, generally, and with some limits on file sizes and numbers, it probably won’t amount to that much more server space required than posts full of inline code.

(On the other hand, that might diminish SEO impact if the code is not loaded along with the request. I am not a SEO expert, so I don’t know if that would be an issue.)

I am not (necessarily) suggesting a companion multi-file “pastebin” that people can dump entire projects into (although, would that be a bad thing?). The directory tree objects need only be accessible via embed tags in a post… though not necessarily by a single post; there seems no reason not to allow other posts—like follow-up or more focused review requests—to refer to the same code tree, or specific files/directories within. But so long as the only way to actually get a file’s contents is via a link in a post, that should prevent the system from being abused as a free file store.

It would be cool if you could not only link to the entire tree—which gets displayed as a tree, with links that will open each file—but also to individual files, and maybe even parts of files… which could be displayed inline in frames when clicked (or by default, maybe). That would allow focusing on just a part of a class/module/project. It even opens the possibility of uploading a whole library, then requesting multiple reviews, one for each class in the library; while each review could focus on just one class, being able to see the larger context would be handy for reviewers.

Granted, this system probably won’t be all that useful for other Codidact communities. And even within Software Development, it’s probably really only useful for the Code Reviews. But on the other hand, maybe giving users the ability to upload files on their user page that they can then link to in posts might actually be generally useful. On Electrical Engineering you can store then share schematics; on Photography and Video and The Great Outdoors you can store and share photos; on Music you can store and share sheet music or even actual music files. In that case, being able to upload a tarball/zipfile (directly or by selecting a local directory, or a git URL to clone from) that holds a source tree would just be a “special” case that mostly only finds use on Software Engineering.

posted 28 days ago

CC BY-SA 4.0

28d ago by trichoplax‭

Indi‭

142 reputation 1 7 14 3

30,000 characters is probably around 1000 lines. That's already too much to ask volunteers on the internet to look thru.

If you're bumping into the limit, the problem is that your post is too long, not that the limit is too short.

posted about 2 months ago

CC BY-SA 4.0

Olin Lathrop‭

1407 reputation 1 41 111 17