Stanze

La sfida a scrivere il codice sorgente C più incomprensibile ha avuto finora 27 edizioni ed ha visto partecipare illustri paladini, come Larry Wall o Fabrice Bellard,.

I programmi in lizza devono essere corretti, cioè compilabili, incomprensibili, ma anche mostrare qualche guizzo creativo.

Tra gli obiettivi citati nella home page del progetto c'è scritto: "To show the importance of programming style, in an ironic way." Nelle linee guida si dice esplicitamente di evitare programmi banali (costruttori di labirinti, solitari, generatori di numeri primi, hello world, ...). Spesso i codici vengono impaginati in modo da mostrare un'immagine, collegandosi alla tradizione della ASCII art. Quella qui sotto è l'immagine del codice che ha vinto l'edizione del 2018:

Ma uno dei fondatori dell'IOCCC, Landon Curt Noll, non perde occasione per avvertire che, per quanto divertenti, i sorgenti inviati all'IOCCC non devono essere considerati dei modelli. Il codice sorgente va scritto come se fosse un'opera letteraria che potrà essere letta tra chissà quanti anni, e deve restare leggibile e modificabile anche da parte di chi non l'ha scritta. In una risposta ad un'email di un giovane che gli chiede auto per diventare un programamtore, Noll scrive:

It is somewhat easy to write a program that works. It requires practice and effort to write code that you can maintain and support. The programs that win the IOCCC (see www.ioccc.org, a contest that I founded back in 1984) are NOT good programs. While they work, and some work very well, they cannot be maintained or improved ... often they cannot be maintained or improved even by their original author.
Parts of a well written program can be reused or borrowed by other programs. Reuse your code when possible. In fact, write your code well (with comments, etc.) the first time ... even if you are just writing a quick 'hello world' program.
If a program is not worth writing well (perhaps because you think it is just a quick test code fragment ...) then it is not worth writing in the first place.
Always, always, always write code as if it will last 30 years ... some of your code can live that long. Write code as if you expect to some back years later and work on it ... long after you forgot the details of the code. Don't write clever obscure twisted hacks. Those write clever obscure twisted hacks are hard to maintain and reuse later.

Source: On becoming an expert C programmer

Prossimo pannello: ⇨ Virus