Is playing reverse code golf possible? Will it ever be?

Question

EDIT: people have pointed out I overlooked the existence of code bowling, which is indeed very similar to what I was looking for, though not exactly what I envisioned it to be. I'll leave this question open though in case people want to share their thoughts about it.

Ever since I discovered code golf exists, I've been fairly obsessed with it. It goes beyond the standard code practices of making your code as short and efficient as possible, and gives a whole new dynamic to coding.

Sadly with me being new to coding and my very limited skills, I'd need to learn a lot more before I could even think of competing. (That, and the only language I'm any good at right now is VBA which seems like the worst choice for golfing to begin with).

However what I am good at is writing convoluted, unnecessarily big, redundant and utterly useless code. Which made me think, is the reverse of code golf feasible? Of course, we all know there are numerous ways of making code near infinite demonstrated neatly by xkcd. Would it be possible to fabricate a set of base rules which is restricting enough to prevent all loopholes and make reverse code golf possible and challenging?

I've been thinking about a few rules myself which would help, but I'm sure I've overlooked a lot of things. Obviously this would only be a baseline, and the challenge should provide additional rules to make it different from other challenges.

1: Limited set of variable/function names. Only use [A-Z]. As above link, xkcd just uses infinitely long functions to pad out their code. This can be easily done with variable names as well. To restrict this, you can only use 26 functions or variables named [A-Z], one character, no longer.

2: Only define each variable once. (With exception of loops) It would be too easy to make your code go A = Hello Worla then A = hello Worlb, etc. through the entire alphabet until you get A = Hello World as is needed. Therefore you can only store a value to a variable once, and it will be fixed until the end of your code. Loops are exempt from that to have variables like counters going up by 1 each loop, or having A redefined for the duration of the loop, until it holds the required value at the end of it.

3: Loops are restricted to the maximum of iterations needed to get the desired output. You could have a loop run from 1 to infinity, where you get the desired output at the second iteration, but pad out your code just by making it run 321985231684320x10^32 etc. times. This is restricted to run twice only as that is when you get the desired output.

4: Code redundancy. Possibly the best/biggest restriction. All code needs to do something directly related to the output. The easiest way to check this: If any lines/blocks of code can be deleted easily without throwing errors or changing the outcome of the code, they don't count and should be omitted. This will prevent people from writing huge code which doesn't do anything, discarding the outcome and finishing it with print Hello World. This would be an interesting challenge for other competitors as well, trying to delete lines of code from other answers to test their redundancy and reduce their score.

5: No repetition. Say I need to get a string of three characters, and I've just written a 5 page essay of code which gets the first character in the string. I could just copy and paste it a couple of times to get the other two characters. But that would be too easy, therefore (within reason) code cannot repeat itself.

6: A restricting time limit/deadline. Say 24 or 48 hours to give everyone a chance to compete, but not a change to go on forever.

7: Code should execute in reasonable time. This one is subjective to how good your hardware is, but the code should execute in reasonable time on a reasonably powerful machine. To prevent people writing code that doesn't execute at all, or executes slower than anyone has patience for, so that nobody can check if it actually works.

8: Only main code counts. All functions called by the code that aren't inside the main body are disregarded.

9: Code is counted until the desired output is given. When the desired output is reached, anything beyond is disregarded.

I have given much thought about this, and this is by no means a complete list of rules needed to make reverse golf possible, as there are probably more loopholes than I could possibly count. Is it at all likely such a complete list will ever exist, making it possible to actually play? If so, what other rules are needed?

Answer 1

The best way to do non-exploitable code-bowling challenges is not to define arbitrary sets of rules that have to be followed by all answers, but to make it cops-and-robbers pitting users who want their code to be long against other users trying to shorten it, like The Bowlers-Golfers Fraction War.

Answer 2

My initial thoughts:

1: is not applicable because many languages do not use standard ASCII letters for function/variable names

2: is not really applicable because it’s hard to say what constitutes a variable in each language (some might not even have explicit variables)

4: is talking about "no-ops" which are indeed usually banned in Code Bowling challenges

5: What about code that repeats itself but for functional reasons?

6: I don’t see the relationship with the rest, and this seems like a bad idea.

7: This depends on the specific challenge at hand.

9: is pretty similar/a subcase of 4. in my opinion.

Answer 3

This is of course code-bowling. The key point to a good Code Bowling challenge is not to have unobservable requirements. Virtually all your "rules" fall into this category.

In my view, there is only one rule that is observable to define Code Bowling.

An answer is only valid if any and all number of deletions invalidate the answer.

For example, if the answer is abc, then bc, ac, ab, a, b, c and an empty program should not fulfil the specification.

Often, this is supplemented with restricted-source to make the challenge more interesting, but this is not a requirement.