Happy (sausage) refactorings

Hi,% habrausername%. I want to play a game with you.

You got a new job. And on the first day, immediately after the signing of the NDA, they show you what remains of the previous developer. You want to scream, you want to run away from this damned place, but the employment contract binds you hand and foot. Therefore, you just barely hear the swearing.
')
From the previous developer left a bunch of code and slippers. You carefully put the slippers in the trash and start refactoring.

This code is terrible. First of all, there is no one who could say why this code was written. Secondly, there is no documentation. Not even comments, let alone unit tests. Thirdly, the code is not structured, and the names of classes and methods do not speak about anything. And finally, it should not start working today, and not even yesterday, but suddenly .
Well,% habrausername%, ran a chill down the back?

In this situation, each programmer believes that now he will do better than it was. But is it? Is the code objectively getting better after refactoring? If so, what is the criterion for improving the code? Or maybe refactoring serves to satisfy the ambitions of a developer?

I bring to your attention a TB MMOG called "Funny refactorings."

The essence is as follows. There is a code leading and N participants. The moderator sends the source code to the post of the first participant. The participant performs refactoring and sends the result back to the leader. Then the moderator sends the result to the second participant, and so on, until the participants finish. The transfer of the code occurs anonymously, that is, none of the participants knows whose code it refactor.

The goal is to get an idea of ​​the "perfect code" and methods that different developers use to achieve it. And of course, it will be fun. Following the results of the Funny Refactorings, an article will be written with an analysis of the changes made, and all the source codes will be posted to the public.

If you want to take part in Funny refactorings, send a request to recrowding@gmail.com. In the application, specify your email (will be used exclusively to send you the source code) and a few words about yourself (they will be published in the final report, this may include contacts, link to the site, and so on).

To prevent chaos, several rules are introduced:

1. Do not hold code for too long. If there is no answer from you for more than two days, you will be excluded from the game.
2. It is not necessary to write in the code any personal data in order not to tempt the next participant to contact you for help. Emails, names, appearances and etc. from the source code will be shamelessly cut.
3. You can not change the programming language. Otherwise, the participant is completely free to act within the concept of “refactoring”. Yes, frank trash will be excluded.
4. The general review will be published on Habré, and the works of all participants in the competition will be uploaded to the public repository along with a few words to themselves, indicated in the application.

For these Refactors, the Java language was chosen (because the Java program can be refactored indefinitely). Applications are accepted until March 18.

UPD If we are talking, I’ll say that the original bunch of code is collected in one file and has a length of no more than 200 lines.

UPD2 To say that I received a lot of applications is to say nothing. I’ll not have enough time to answer everyone physically, and I don’t need it, I guess. The main thing is that all incoming applications are recorded, and the source codes have already begun to sail. Have patience, everyone who sent me an email will eventually receive an archive with a code.