# Keep your golfing in your code, not in inputs and outputs

I am becoming more and more annoyed at the ever-increasing number of rules about what is deemed acceptable as inputs and outputs to programs

Here is a compilation of such rules that I found:

To me, there is absolutely no need for all of those posts, for the following reason:

Code golf is about golfing your code, not golfing the input or the output.

• A challenge gives you numbers as input? Then you take a number as input and not something ridiculous like the empty string instead of 0.
• Booleans either exist in your language and you use them, or you use 0 and 1 as is historically done, nothing else.
• Unary is not the natural representation of numbers in almost all languages, therefore it makes no sense that you can take an input number in unary or return it in unary for said languages, instead of what's natural in said languages (almost always decimal).
• ...

In short, you should take inputs and return outputs as is naturally done in the language you use, and not abuse the format of the input/output because it shortens your code. If your algorithm is shorter on unary numbers, then fine but the conversion from and to decimal goes inside your code, not outside.

### Why I think this is important

PPCG is graduating, and is often listed in the Hot Network Questions. We often have discussions e.g. in chat or in comments of "bad challenges" that it is very difficult to enter this community.

I strongly believe those input/output formats deter newcomers from participating in challenges, because, just like for me, the idea of taking as input numbers in unary in a Python program seems completely ridiculous to outsiders.

Getting rid of all this also reduces the number of rules that a newcomer needs to know before posting (which there are a lot of already).

• I agree that our wealth of implicit rules and and meta consensuses (consensi?) is becoming a problem, but I definitely don't agree with your reasoning in a lot of points. For instance, decimal input is technically a lot less of a natural input format than e.g. reading numeric values straight from bytes on STDIN. Also having to use 0 and 1 as truthy falsy in all languages just because that's what is historically done means some languages would have to write really awkward code, if they simply have different truthy/falsy semantics. – Martin Ender Jul 4 '16 at 12:16
• In general I'm in favour of doing whatever is natural in your language of choice (since I don't believe in inter-language comparison anyway), but leaving it at that tends to be too vague to avoid lots of arguing and rule-lawyering as well. – Martin Ender Jul 4 '16 at 12:16
• I agree that some of our allowed input formats are rather permissive, but surely you'd grant that some specified standard is needed? – xnor Jul 4 '16 at 12:17
• @MartinEnder It's too vague only for people that are not acting in good faith and want to reduce the length of their answers at all costs. Dealing with such lack of good faith in abusing inputs/outputs should be done the same way other things are done on SE sites: through downvoting, not through thousands of rules on meta. – Fatalize Jul 4 '16 at 12:21
• Personally, I think the best option would be to have a simple set of rules specific to each language. It would simply be list of valid submission/input/output formats for the language, accepted list types and a truthy/falsy definition. Within any given language, I'm pretty sure people would be able to agree on consistent rules, and this would give a fair competition within each language. If SE had a meta data field for the language, then this simple set of definitions could even be displayed while writing the answer. Without it I'm not sure how to make them discoverable for new users though. – Martin Ender Jul 4 '16 at 12:21
• @Fatalize People even upvote intentionally invalid answers. How do you expect them to treat dodgy edge cases with downvotes? – Martin Ender Jul 4 '16 at 12:22
• @MartinEnder "For instance, decimal input is technically a lot less of a natural input format than e.g. reading numeric values straight from bytes on STDIN" That's a technical argument of naturalness. When someone asks a challenge about arithmetic, the natural input format is decimal numbers. Technicalities are in your code, not in your answer or in the inputs you take to an abstract problem. – Fatalize Jul 4 '16 at 12:24
• @MartinEnder Most people don't though, so I would expect that the same would be true in this case. Especially if a comment is added to the downvote explaining what the abuse is. – Fatalize Jul 4 '16 at 12:27
• @MartinEnder I'm definitely in favor of having a set of rules for each language though. Even if this is still hard for newcomers to find, it would 1) be centralized 2) specify the same cases for all languages 3) lead to much clearer consensuses. – Fatalize Jul 4 '16 at 12:30
• "Most people don't" [citation-needed]. This answer uses code points, even though the challenge explicitly asks for decimal I/O, and it got 9 upvotes before getting the first two downvotes. And this isn't an exception. I believe in many such cases the upvotes are coming from people via HNQ who don't have enough rep to downvote. They'll continue to upvote those, whether we disallow dodgy input formats or not. – Martin Ender Jul 4 '16 at 12:31
• "It is very difficult to enter this community." I agree, I still haven't found a way to enter this community :(. – NH. Aug 16 '17 at 16:38

I tend to agree that there are a lot of rules for new users to "discover", and that this is a bad thing (in general). However, I don't agree with your solution, because I don't see how it's any clearer at all. For many challenges and many languages, there isn't a single most "natural" representation of input:

Challenge: Sum the input list of numbers

Ok, so what's the most obvious way to take input? In Java for example, you could take them from STDIN as strings (eww), or as an int array to a function. Oh wait, maybe an ArrayList instead? Hmm, maybe some other sort of List has some nifty builtin? Oh, right, I could use one of those stream things to do this I bet...

Now obviously this isn't the same as taking input in unary. Or is it? I mean, I guess I could take input as unary and just sum the lengths. Probably wouldn't make it shorter, but it would work. But what's the actual difference between that and deciding what sort of list to use, or whether to pull it from STDIN?

I'm sure you can come up with very simple examples for many languages to illustrate the point. There are multiple ways to take inputs in most languages for a reason, and I for one wouldn't try to argue with what's considered most natural. Sure, some are less natural than others, but that's a fine line to walk, and a hard border to draw.

Code golf is about golfing your code, not golfing the input or the output.

This sounds right and noble, but I don't think it's actually true here at all, nor should it be. In my opinion, we should be inspiring creativity, and encourage alternative ways to shorten the code. It's why I asked "What's a string?", which isn't in your list above. Using a char[] is shorter in many cases, and it's not usually the "most natural" way you'd want to do it in production code1, but I don't come here to write production code2. Choosing between String and char[] doesn't seem like much, but it's the same class of choice you're talking about when you talk about booleans or unary.

There are many ways to shorten code, and you have to choose among them for each particular challenge. The only way I see to get around this is to write strict rules for every. single. language. I see that as a recommendation in comments, but I think that would only lead to even more chaos. Since we accept any existing programming languages (and write our own from time to time), that's simply a recipe for disaster.

After literally years of adapting our input/output rules to accommodate oddball languages and generally leaning toward leniency, I think this would be a huge step in the wrong direction.

1: Seriously. People will fight you for trying this in most workplaces. Like, a fistfight. Don't do it.

2: Also, it would probably break the small piece of my soul that still likes C to hear that char arrays aren't the same things as strings, in any context.

• Did someone say char[]? Puts on brass knuckles – Alex A. Jul 5 '16 at 17:49