I find it weird that Cemetech Contests are graded on source code. Most people have a contrived idea in their head of what good code is, and yet other people write impressive programs without adhering to those ideas
.

As an example I read in CC26 that "Quantity of Comments" is a consideration?
But I always try to write my code in a self explanatory way that doesn't require such comments. I think helping others' initial resistance to learning a code base isn't a valuable consideration when it compromises the malleability of a codebase (depends on your goals though, open source or not for example).


So I find the end result much more important than the means used to get there.
In fact, the resulting program is the best measure of source code. (If you argue for extensibility, I believe that still falls under the "resulting program" since that will tell whether you were able to add everything you wanted.)

(I also think the skill curve of programming is highly exponential and that it would be hard to find judges that can differentiate how others' code may make good professional software, and because of this exponential curve the cost of that is large. But there's no easy solution to this.)

Personal experience. When I submitted Fire and Flames to CC25, I received comments from multiple judges that I should have broken the code up into multiple files. The game was 2,000 LOC. I use text editors in such a way that there is little tangible benefit to splitting code into multiple files. Due to this feedback, I made a few future projects with code split into multiple files with intention, and I found increased resistance on file boundaries for little personal gain. Often the advice people have to give (split code into files, keep functions less than ten lines, use OOP) are things that if one adheres to it, it doesn't actually become easier to write the programs one wants to write. Because it's surface-level advice. It's not advice on how to write the code that runs your program, because that advice is hard to give well.
I'm currently developing a PC game that is 33,000 LOC, with one file containing much game logic spanning 12,000 LOC. Functions span thousands of lines and are easy to change or factor out as needed. I am still able to efficiently add features and work on the game daily.
Do not think about how such means fit your personal learned paradigm, and instead think about whether an end product is created through such means.
Source code reviews from people who have trained their brains differently, use different editor workflows, and are uninvested in the project are inherently surface level. (Uninvested in a project means not beyond a codebase's initial learning hump, which I find inconsequential)

Maybe source code review ought to not count towards final rating of a program? It can be a comment. Though with how sure people are of their ideas, it may be hard to remember to take it with a grain of salt.

I rarely use comments and mostly just write my code for myself. Being Self Taught mainly, there is a lot of different styles. Source Code review should only focus on optimizations, as there is multiple ways to do things, and we run on limited hardware. Only extremely inefficient code should even be considered into the final score. Amount of files shouldn't be part of the criteria, unless if there is an excessive amount of files or multiple lines of code are not findable. Keeping functions to a count of lines would have to use multiple functions to do one bigger functions job, and execution order would be borderline untraceable.

Extremely inefficient code isn't a problem to me. It's when there's a tangible effect on the end product that it matters. So I don't think this judgement should be at the source code level, as I mentioned in the post. I often leave code unoptimized if it has zero effect on the end product (there are performance-critical areas, and there are non-performance-crticial areas)

I disagree, see my comment:

Thinking there are too many files may be an issue with your editor workflow. See Java, which is an IDE-oriented language. Try navigating a Java project in your terminal. It will be painful.
If lines of code are not findable, then perhaps you have not gotten past a project's initial learning hump, which I find inconsequential for my own projects.

The other things you said seemed reasonable.

What I actually meant, worded it wrong.

Too many files meant excessive breaking code up between multiple files. (Putting functions in different files that should be grouped together, I.E. graphic code in 2 files with 2 functions each instead of 1 with 4 functions. The functions in this case not being very long and unreadable together.)

What I actually meant, worded it wrong.

Too many files meant excessive breaking code up between multiple files. (Putting functions in different files that should be grouped together, I.E. graphic code in 2 files with 2 functions each instead of 1 with 4 functions. The functions in this case not being very long and unreadable together.) All code in one file is also problem for larger projects (Would consider 12000 reasonable depending on content, 33000 not so much.)

Your thoughts contrast mine in being based on your own conception of reasonable programming. Everyone has thoughts like this, and I disagree with their usefulness. I may find it dumb that classes are split per file in Java, but that's just the way Java is meant to be programmed. It's an IDE-oriented language. I.E. graphic code in 4 files with 1 class each instead of 1 with 4 classes. Whether or not it's a good paradigm is completely separate from whether or not we find it excessive, and that is too complicated to answer right now anyway.

...given your current thought paradigm. You may be in a local minimum where that is the way things work, but that is not the way things must work. This is not a problem. This is your problem.

Arbitrary.
I did like that you threw in "depending on context" though.

Functions, not classes. In my example case, It would be 2 files with one class each and two functions each instead of one class in one file with 4 functions.

Okay, fair. It really depends on the language though and the coding style and skill of the writer. As I have already stated, there is multiple ways to code something correctly.

I find that disambiguation irrelevant.

I find this post and the quoted post irrelevant.

Sometimes zero comments is exactly the right number of comments, and as a contest judge, there have absolutely been times when I've reviewed the code and given full marks despite no comments and stylistic differences. "Quantity" isn't the best choice of words for that part of the rubric.

That said, I like the idea of it being a section for comment but not scored. I think the exceptions would be in cases of a tie, or if there are obvious bugs in the code that didn't surface while testing. In theory, if during the code review you find such a bug, you should though then test the contest entry to see if that bug ever manifests. Maybe it's dead end code, which therefore should be commented on, but in the case of the contest entry maybe shouldn't be a reason to lose points.

To me, the code review in the contest really serves as an opportunity for people who would otherwise not have their code reviewed. It fits with our general theme of teaching cool things, but of course, you're absolutely right that there are a lot of things that can be found in a code review that are opinion.

Overall, I could go either way. But I definitely see your point and agree in general. It's weighted low so it doesn't impact score too much overall for these reasons, but maybe even then it's not really fair to include in the score.

"Let's judge a coding contest on anything but the code"

To me, code is a means to creating a program, and the contest is about making a program.

"Let's judge a chair-making contest on the hammer you used."

I can see how you can have a different view of the contest, and that is fair.

Regardless of how well it sits, whether it looks structurally sound is sure to be judged.

I agree. If you sit and it falls over, that's a problem. So we may test it by using it.

Here's my two cents

Code organization and commenting isn't necessarily important for the person writing it, it's your code so theoretically you'll feel comfortable in whatever environment you wrote it in. However, if you are hoping to have other people help or collaborate, it's important that your code isn't just what works for you and is easy for other people to understand. Well organized file structure, lots of comments, and simple functions make it easier for a random person with no experience in said project to jump in and help, and if you have an enormous single file with many thousands of lines and no comments, that's good for you, but much more challenging for someone else to help with.

However, if you've carefully spent time and effort splitting up unique parts of code, sure it takes more time, but it will also make working on the project and receiving feedback from other people far easier, and be easier to re-write certain parts and keep others without needing to have the whole project in your head at once. I've also found (and this could just be me), but breaking a problem into smaller parts and files / functions makes it easier for me to understand and solve.

For me, this is also important because I know if I revisit my project a year or two in the future, I won't have the whole thing fresh in my head and it'll be a lot harder to work on it again. Messy code also tends to make debugging more challenging.

TLDR: If you're the only one working on the project and intend to keep it that way, do what works for you. If you want to collaborate with others, put some time into making it easier for them to help out. Not sure exactly how I feel about it being judged on, but I do feel like it makes sense if you know that code quality is being judged to put some effort into making it easy to read. I don't feel that it is unfair if it's listed in the topic as something being judged on.

All code is crap. Some just smells better.

All well and good but a possible counterpoint: If they only learn the code-base once, then you may have made the next 1,000 hours of fluent work 30% worse to help their first 20 hours on the project. This may be a consideration for some situations.

Also I believe that given 1,000 hours of exposure to a "messy" code style, it will become intuitive. Our brains can be magic if we leave them malleable. So it becomes less a question of "I want to write non-messy code" to "all code is messy, which sort of code would be best to learn to intuit?"

I think I may have been the one who originally proposed the "code quality" category, and I would say that I'm probably less in favor of it now than I was back then. I think the idea then was that we wanted to encourage people to post code that was easy for other people to learn from, as well as to reward people for doing particularly creative stuff in the code that wasn't necessarily visible in the final program.

I agree that "quantity of comments" is not a particularly useful metric for judging code quality, and does not really fit into that original spirit of the category. In programs with lots of comments, the comments are either adding information that should have been represented in the code (e.g. variable names) instead, or repeating that information, which violates DRY and increases the odds that you get incorrect information after changing something and forgetting to update the corresponding comment. This doesn't mean that you shouldn't comment your code, just that comments should only be used to convey information that can't be conveyed through the code itself.

The label "code quality" lumps a bunch of concepts of the form "if you want your code to have property X, you should do Y" together, and people tend to take "code quality" concepts as gospel even when they haven't considered whether they even want their code to have each property X. It makes no sense to apply a concept that's supposed to make it easier to scale up codebases to a 100-line Python script. You can argue whether a particular technique Y is effective at doing X, but it's pointless to try to discuss whether Y is "good" without determining whether you even want to do X in the first place.

Not every project is going to have the same requirements. A lot of "code quality" concepts are effective at making sure that two people can work on a project concurrently without having to constantly synchronize with each other, or at making onboarding of new contributors efficient, but those will be useless if you don't intend on ever bringing on another contributor. Contests are kinda in a weird spot here, because the contest organizers are in a position to decide some of the requirements of the project. If the contest is intended to create new programs from others to learn from, the judging should reflect that, which creates the requirement "it should be easy for people trying to figure out how the game does Z to find out where in the code it does Z and how Z works."

As far as "using multiple files" goes, in my opinion the main goal of that is to make module boundaries explicit. Trying to split stuff up between files isn't particularly useful if you're not writing code in a modular fashion. I typically find that, if the module boundaries are located in sensible places, stuff being in multiple files doesn't actually affect the speed at which I navigate code, since I mostly work within a single module at a time and use "jump to definition" and "back" when I need to move up or down a layer of abstraction. Files being difficult to navigate when using a modern IDE is probably a sign that the module boundaries I've laid out in the code aren't in an ideal spot, and that I should refactor stuff in order to actually get the benefits of modularity.


Beyond a certain scale, it's not going to be possible for a single person to fit the entire codebase into their head at once. For larger programs, I don't think it's really correct to consider "learning the codebase" as a one-time expense, but rather a continuous process of becoming familiar with parts that you haven't touched in a while.


There's a relatively small number of ways to write "clean" code, whereas there are as many ways to write messy code as there are programmers. It's convenient if we can for the most part agree on conventions for writing code. While reading "messy" code is an important skill, I don't think it's one that you're going to lose by trying to write "clean" code. I tend to find that the code that I initially write is pretty messy, since I haven't fully explored the problem yet. Writing "clean" code isn't about exclusively thinking about and writing clean code, it's about taking the "messy" code I've just written and trying to reduce the number of problems it's going to cause for me later. You still have to deal with interpreting "messy" code on a regular basis, as part of the process of cleaning it up, so you aren't going to forget how to do it.

My rule of thumb is to make it as optimized as possible on one file even if it ends up taking more space just because when I download other peoples stuff, I always breathe a sigh of relief when its just one file. It makes it a lot easier. Also, I've never considered having comments. I didn't realize until now that that was a factor.