Code-golf is a competition to solve a particular problem in the fewest bytes of source code.
What is code-golf?
code-golf is a competition to solve a problem in the fewest bytes of source code.
How should I solve a code-golf challenge?
Pick your favorite language, solve the problem, and squeeze the size as much as you can!
Answers to code-golf should contain a piece of code that completely meets the specifications of the challenge, as well as the language that it's in and the length of the answer. The standard format for this is:
[Language], [Number] bytes
[Link to code]
If possible, include a link to an online interpreter with your code running on the test cases, so that others can test it and try to improve it. Try It Online is often used for this purpose for the many languages it supports.
An explanation as to how your code works is helpful, especially if your answer employs creative techniques.
Also, familiarise yourself with the loopholes that are forbidden by default, and make sure your answer doesn't violate any of them.
Defaults for input and output
Unless the challenge specifically says otherwise:
- Answers may be either full programs or functions (or equivalent).
- Functions do not have to be named
- Both programs and functions may take input via STDIN or command-line argument or prompt. Functions may also use their function arguments for input. Both programs and functions may output by writing to STDOUT. Functions may also use their arguments or return value(s) for output. These defaults are based on community consensus.
How do I shorten my code?
Most of the time you'll need to use idioms discouraged for clean code. The standard approaches are:
- Remove unnecessary spaces and new lines.
- Use one-letter variables instead of descriptive names.
- Study the language and the built-in libraries thoroughly. There are often “hidden” features that can solve the problem in fewer bytes.
- Check for implicit conversions between types. A boolean or character might be the same as an integer for some uses.
- Many times, a more inefficient algorithm can reduce the code size. (Example)
- Go through the tips question for your language to see if any tricks there can reduce your byte count.
Things to note
- Answers that use Unicode code points outside 0 to 255 should state the encoding used.
- It is accepted practice not to count as part of the score compiler flags or any other non-standard marks required to get the interpreter/compiler to do what you need it to do.
- You should show how the program or function is executed, accepting the input, and printing the output.
Writing a challenge
So, you want to write your own challenge? If you're new, consider posting some answers first to get a lay of the land. Post your challenge in the Sandbox first to get feedback on it.
What are the requirements for posting a code-golf challenge?
There should be a complete, unambiguous specification of the problem. It must include at least:
- The input format.
- The output format.
- A clear description of how the input and output are related.
- Example inputs and corresponding outputs.
All programming languages should usually be allowed unless there are exceptional circumstances outside of personal opinion. Likewise, don't override community defaults for input and output format unless there's a particularity good reason.
If source code length is not the primary scoring criterion, consider using another tag instead. Code golf questions should not have bonuses that give a reward like "-10 bytes" for meeting some condition.
If you wish, you may include restrictions on the code used in submissions (restricted-source) or its performance (restricted-time or restricted-complexity). Any such restrictions must be objective and observable from the source and its execution. Subjective restrictions like "use this method" or "follow the spirit of the question" are not allowed.
What makes a good code-golf challenge?
A good code-golf challenge is:
- Unambiguously specified.
- Explained well enough to be understood fully in at most two readings.
- Admits rapid naive implementations.
- Complex enough to admit more than one reasonable way to accomplish it.
- Designed with more than one class of languages in mind.
- Not too closely related to others we've done recently.
For more reading there is Things to avoid when writing challenges on our meta site.