Badcode

Badcode is an idea of an esolang by User:D, who decided to post here after making no progress in designing the language.
The language tries to prevent clean code as far as possible, from a language's perspective.
Typically, programs written in Badcode are long-winded, requiring the use of a lot of variables and built-in functions to reconcile & fix random effects that are unintended by the programmer. Furthermore, programs are really time-consuming to write, since the program logic you have in your first try usually does not work in the interpreter. You'd have to modify your logic significantly to make it work. (This makes the language as annoying to program in as brainfuck, despite support for staple functions & statements you'd typically expect in practical languages.)
== Design Goals / Aspects ==
* Only allow definition of 1 or 2 byte variables (all of which are global). This prevents readable variable declaration altogether. Furthermore, they can only be defined with alphabetic characters, adding to the likeliness of confusing two variables and making mistakes.
* Comments cannot be defined. (That way, it's impossible to explain your code in projects.)
* Changing a single byte in the program will alter the functionality of the rest of the code completely. And it's not a syntax error. This violates the fragility and rigidity principle: changing even a small part of the code can make the code do something completely different.
* Defined functions can only be large. If your function is too short, it will not run. That way, you have to do multiple things in your function in order to meet the requirements (with the lack of comment syntax).
* User-defined Functions cannot be defined without at least 10 arguments. This does not apply for built-in functions (which often only have 1 or 2 arguments, at most 3 for the elvis operator). But the names of the builtins are 1 or 2 bytes each, and it's very easy to confuse them with your variables.
* Principle Of Most Surprises. You may expect a straightforward construct to do exactly what you want it to do, but actually it does something quite different. E.g. Random side effects, unexpected control flow, etc. (Like the break problem in C switch statements. People often forget to write the break, and the code falls through (a functionality that is not often useful or intended).)
* Terrible & Weird rules for whitespace handling. This means you cannot format your code properly with whitespace (and make it readable), but instead in weird, hard-to-memorize rules.
== tl;dr ==
Basically, this is asking for a language with a lot of flexibility in syntax (except for whitespace). Syntax that do totally different things have a low Levenshtein Distance from each other.
Furthermore, the normal built-ins and syntax wouldn't exactly do the effect you need, at least how you would normally write them. They'd have surprising side-effects, or unexpected ways of executing your code. You would have to write code to fix that effect to make it work.
Apart from that, it's just introducing some weird restrictions to prevent clean code from being written.
== External Links ==
* BS, a language with similar goals.
Category:Languages
Category:2023
Category:Ideas
Category:Unimplemented