DevHub Contest: Rules and Scoring Criteria

The idea

A game, a tool, a simulation, a website, a bot, an app: the theme is free and so is the language. The only real constraint is that the project is yours and that you can explain it.

Schedule

Who can take part

• Any DevHub member. Not a member yet? Join the server.
• Solo projects. Occasional help is fine, but most of the code must be yours.
• One project per participant.
• Staff members do not take part.
• A project started before the contest is accepted, even encouraged: we prefer finished projects.

What to submit

• A Git repository (GitHub or GitLab), accessible to the jury. It doesn't have to be public, but a public repository earns the open source bonus.
• A README saying what the project does, how to install it and how to run it.
• Three screenshots and a short demo video (30 to 60 seconds). The community will vote on the UI based on these: most voters won't install every project.
• The completed registration form: a ticket opened on Discord.

The scoring grid

The final score is out of 100, plus up to 2 bonus points: 102 at most.

Code quality · 30 points

We measure readability and maintainability: function complexity, length, duplication, dead code and respect for the language's conventions.

This score comes from an automatic static analysis tool, the same for every project. Its name will be revealed on January 1st. It stays hidden until then so that you write good code, not code that passes a tool. What it checks is no secret: it's the list below.

Two cases fall outside the automatic process: a project too short for the tool to score reliably, and a language the tool doesn't support. In those cases, the staff adjusts the score, and every adjustment is explained publicly with the results. The exact rule will be announced before the deadline.

What costs points

• dead code: functions never called, unused variables, whole blocks commented out "just in case";
• functions that are too long or too complex. Cyclomatic complexity counts the number of possible paths through a function: each if, elif, for, while, and, or or except adds one. Above 10, the function is hard to read and test: split it up;
• nested conditions and loops over several levels, when an early return or a separate function would do;
• duplication: the same block copy-pasted in three places instead of one function;
• names that say nothing (data2, temp, x1) and endless lines.

Algorithms and mathematical logic · 25 points

We look at whether there is real logic behind the project, and whether it is well built.

What earns points

• real business or scientific logic: simulation, procedural generation, pathfinding, physics, rule engine, data processing, compression, game AI…;
• data structures chosen for a reason: a dictionary or a set for fast lookup, a queue for breadth-first search, a heap for a priority queue;
• awareness of complexity: knowing why a loop inside a loop over 10,000 items is a problem, and avoiding it.

What earns little: algorithms that only serve animations or visual effects.

UI / Design · 20 points

We look at visual quality, consistency (colors, typography, spacing, components) and ergonomics: can someone figure out how to use the project without a manual?

This score is split in two: 10 points from the jury and 10 points from the vote of DevHub members, based on the screenshots and the demo video.

How the vote works

• The conditions to be a voter (seniority, level) will be specified before the vote opens.
• Each voter rates the projects from 1 to 5. They don't pick a single favorite.
• Participants can vote, but not for their own project.
• Projects are shown in random order, different for each voter.
• Results stay hidden until the vote ends.
• A project must receive enough votes for its average to count fully: two ratings of 5 don't beat thirty ratings of 4.6.

For a project without a graphical interface (command-line tool, API, bot), we grade the quality of the interface that exists: clear messages, help, readable output, understandable errors.

Robustness and tests · 10 points

• The project runs by following the README and doesn't crash in normal use.
• It handles errors and edge cases: empty or invalid input, missing file, network down, extreme values.
• It includes automated tests that run with a single command (for example pytest, npm test). A few useful tests are worth more than fifty tests that verify nothing.

Git repository management · 5 points

• Commit messages that say what changes ("Add collision between enemies", not "fix" or "update").
• A readable history, with regular commits rather than one giant commit the day before the deadline.
• Branches used where they make sense.
• A clean .gitignore: no virtual environment, node_modules, build files or editor files in the repository.
• No committed secrets: a token, a password or a .env file in the history costs points, even if it was deleted afterwards (it stays in the history).

Originality · 5 points

The uniqueness of the idea and of how it's handled. Yet another to-do list can be original if it approaches the problem from an unexpected angle; a Snake clone isn't if it's identical to all the others.

Documentation · 5 points

• A complete README: what the project does, screenshots, installation, how to run it, technologies used.
• A CONTRIBUTING.md explaining how someone else could contribute.
• Useful comments, which explain why the code does something, not what it does. # increment i is useless. # start from the end so we can delete while iterating is useful.

Open source bonus · +2 points

The repository is public at grading time and includes a license file (MIT, GPL, Apache…). A public repository without a license isn't open source in the legal sense and doesn't earn the bonus.

Ties and appeals

• In case of a tie, the participants involved answer tie-breaker questions about their project.
• An appeal about a score is made by ticket within 3 days of the results. The score breakdown for each criterion is provided to any participant who asks.

The prize

The winner chooses two prizes:

• a mug or a mouse pad in DevHub colors with their profile picture;
• a subscription to the code analysis tool or a domain name.

They also receive the "end of 2026 contest winner" role. Custom prizes may reward a project that excels on one particular criterion.