Post History

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, any 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:

| Project                                                                                    | Characters |
|--------------------------------------------------------------------------------------------|------------|
| [“snake” game](https://github.com/Tippydes/SDL3-snake-game/blob/main/src/main.c)           | 47,278     |
| [“argparse” library](https://github.com/coreutils/coreutils/blob/master/src/cat.c)         | 85,932     |
| [`cat`](https://raw.githubusercontent.com/coreutils/coreutils/refs/heads/master/src/cat.c) | 29,299     |
| [string class](https://codereview.stackexchange.com/q/275633/170106)                       | 26,975     |

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.