Coding: Bigger is Better!

  1. Part 1: My Genesis
  2. Part 2: Ancient History
  3. Part 3: Modern Times
  4. Part 4: The Point
  5. Part 5: The Solution

Part 1: My Genesis

First of all, I should start by saying it's good to see coding challenges. When I first learned to code, at the age of eight, I had to come up with my own methods for everything. If I wanted to calculate prime numbers, I'd have to think up each step myself. If I wanted to reverse a string, I'd have to think up each step myself. If I wanted to do anything, I'd have to think up each step myself. This meant most of my methods were inefficient, but they worked.

When I was ten, my family got Internet access for the first time. Finally, I could utilize the methods of others, and improve my own code. I quickly taught myself HTML, built a small personal webpage at geocities (back when it was good), then joined the Geocities Help Chat. I quickly became an active helper there, under the nickname "Mr. Helper". One of the things I emphasized was the use of small comments in javascript, to briefly describe methods.

It was through my friends from Help Chat that I finally got to IRC. I immediately learned mIRC script, and have kept up to date on it since.

Part 2: Ancient History

Back when I first learned script, the state of IRC was quite different than what it is today. There were few server-based protections against flooding, and even less that were effective. Most users were on dial-up connections, and had computers too slow to handle massive amounts of incoming text, so if you got caught by a flood, you were doomed. From the need to protect myself from these floods came a deep respect for efficent script.

After getting my first programming job, I found a fact of life that all too many coders miss: Your code isn't really yours. Each program I wrote had to be read by others after I left, so the few comments I used weren't sufficient. In addition, the single-line methods to do complicated math functions were unreadable by anyone else. I adjusted my work pattern as appropriate. I would write my unreadable code, then fix it. This solved the problem temporarily.

Part 3: Modern Times

After taking a long break from IRC to graduate high school, I returned to find that things had changed. DSL is now the minimum connection, servers don't allow hardly any bots anymore, and the server is the first line of defense against floods.

With a few college programming classes under my belt, I learned that my old work patterns wouldn't help me. I didn't have time to go over the code multiple times. Accordingly, I changed my habits again, focusing on writing readable code, rather than short code. At one point, one of my professors gave a simple rule of thumb: a program is only one third code, and two thirds explanation.

Part 4: The Point

(For the purposes of this document, I'll use the words "coding" and "scripting" interchangably here, since script is just interpreted code.)
Now on IRC, I see many challenges posed to scripters. Most of these challenges are essentially contests, and there is one common way to judge them. They are often judged using the countcode.mrc script. This script gives the size in bytes of a mIRC script file, discounting only blank lines and indentation. Generally, the smallest script wins the contest. This is utterly rediculous. Emphasizing the use of single-character variable names, no comments, and excessively-compact code goes against all standard practices. It is often stated that these contests are to encourage scripters to be creative. This is not a good kind of creativity. This is the kind of creativity that leads to inventing atomic bombs instead of nuclear power plants. This is the kind of creativity that leads scripters, once they move into "real" code, to release abominable code into the public.

Why is it abominable? Because unlike what every programming class teaches, unlike all real experience, and unlike all common sense, the winning script for the contest is almost always unreadable. The countcode.mrc script (at the time of this writing) includes comments in the file size. Thus, scripters are encouraged to not comment their code. Also, since splitting up large expressions requires more characters, you'll often find nested code that's nearly impossible to understand.

THIS IS NOT ACCEPTABLE!

There is no reason to encourage poor coding. Indeed, encouraging bad code is the mark of a bad coder.

Part 5: The Solution

Since encouraging unreadable code isn't a good idea, then what is? We want to encourage creativity, but in a better way than a contest to create the most unreadable code possible. Instead, we must consider what coders really need for today's requirements. With users demanding ever more eye candy, more computational power is going to visual effects, leaving less for actual productive routines. In addition, even with the exponential increase in computing speed, the demands on programs are increasing even faster. Therefore, I suggest a change in the way contests are judged. Rather than encourage creative ways to make code unreadable, encourage creative ways to make the code more efficient. Judge the code by its speed for a normal operation cycle. Yes, the test is more complicated. Yes, it will require more work by the judge. However, this work is necessary to ensure that the winner of the contest is indeed the one whose code is best.

At the very least, the method for counting the code size should not include comments. In addition, all whitespace should be ignored, not just blank lines and indentation. Even if the intention is wrong, the contest should at least allow the code to be readable. Once the code is able to be understood, and winning entries are made available to the public, the contest will at last be beneficial to the coding community. Until such time, poorly-designed contests will continue to be harmful to the contestants.


"There is nothing in the programming field more despicable than an undocumented program." -Ed Yourdon

Part 6: Follow-up

It seems mircscripts.org, one of the most well-known scripting-contest sites, has changed their method of checking code length. Rather than show the world their horrible method for checking the script's length, they now use a PHP script to do the same function. However, their idiocy is still evident, as can be demonstrated with the following valid mIRC code: 
;This is an example of how retarded this script is.
/*
A good counting script will see this as 20 meaningful bytes.
*/
alias SartenX {
  return %this_is_easily_seen_as_a_descriptive_variable
}
Hiding their judging method like this is dishonest at best, and a horrifying descent into coding hell at worst. To continue the blatant stupidity, their latest (as of this writing) challenge doesn't allow certain built-in functions to be used. This is even worse that emphasizingcode size! Now, rather than using built-in functions which are often faster and more error-free then what any individual programmer can do, poorly-built hacks are used. No military commander would go into battle lacking their most ideal weapons. To even ask such from a programmer is worse than awful. It is a travesty.

Back to top
Back to Sarten-X.com

Valid HTML 4.01!