I came across a story from the Solidot (A Chinese version of Slashdot) this morning that one of the developers in Fcitx project finally decided to terminate it, one of the top open source (GPLed) Chinese input method project on *nix platform. For English-speaking users, the importance of the IME might not be fully realized. For Linux users living in East Asia, IME is somehow equivalent to keyboard. IME is so critical to the software platform such that Google also has developed a Chinese IME recently. So, why did this developer make this decision to terminate such a significant (and also a well-known) project? According to the main page of the project, the core developer got pissed off by an other developer who criticizes this project as a “poor and ugly” coding style. So my question arises: can we developers in the open source community criticize others’ projects on the basis of “coding style”?

Further reading prompts me that criticizing others’ coding style is very common in the open source community. I am not an expert in coding per se, however, I have at least 10 reasons why we shouldn’t have the holy war on the coding or design style towards other developers.

1) In open source community, coding is for run or for fun, not (merely) for read.

Traditionally, most people would thought that the skills that required to write one’s own software are so advanced that one could never hope to write his/her own code one day. However, lots of advanced programming tool such as IDE and some high-level script language have inherently remodeled the schema. Now, lots of beginners are willing to write some code to get things done; and they are as passionate as the gurus to put their code in the public domain. Consequently, their ugly coding/design style has been criticized by others in the community for “not readable” or “not beautiful”. However, what is the purpose of the open source movement? I would like to say that open source movement is about sharing and freedom—you can learn from others and do whatever you want. However, no one in the open source community aims to write the “textbook” source code. We basically write the code for a special purpose. Therefore, people should not criticize form an aesthetic perspective. After all, the coding is for run or for personal fun. Coding for reading is not the purpose per se–at least it is not the original purpose. So, we have to bear with the truth that every developer has his own coding/design style; even sometimes the style is goofy.

2) Style is highly restricted by the language feature, or, the ‘native’ programming language this developer uses.

It has been quite a long time since PERL was first time called pathologically eclectic rubbish lister. However, as I know, lots of researchers around the world use PERL on a daily base. In our department, many colleagues use PERL as their ‘native’ language despite that PERL is somehow write only. Provided this, it is unfair to judge others’ coding style as it differ from language to language. For example, my ‘native’ programming language is Java. When first time I read the book “Text Processing in Python”, I found that “map” operation is amazing when I need apply some homogenous operation on every element in a container with iterator. However, in practice, I still cannot help using “for loop” instead of “map”. As syntactical sugar differs from language to language, it usually requires quite amount of experience before one actually realize the right coding style in some programming languages other than the native one. Therefore, the holy war on the coding style here is similar to the holy war on English and Spanish, which is vulgar and intolerant.

3) Design pattern and coding style reflect the underlying thinking, or different design purpose, which might be difference from person to person.

If you Google “code style”, you will find tons of guidelines ranging from kernel programming to CSS coding style. This is because for a robust and collaborated open source project, a nice coding style will significantly reduce the communication overhead as well as the time wasted on the maintenance. However, what if some one is going to write a system or framework from scratch?

Basically, a coding/design style will somehow reflect the underlying idea. For example, I guess I am not the only one who dislikes the wrapping design in the Java.io package. In order to use a single Unicode string reader from file, you have to warp the FileInputStream with several objects; while in C++ or python, a single statement settles all the chaos. However, the idea of Java IO is putting least assumption upon the IO stream and providing the programmer with the most flexibility. Therefore, merely criticize the coding style to use Java IO or the design of java IO is gratuitous. Frankly speaking, I do not feel like the design style of Apache Struts as it is very complicated for me to deploy a small system (That’s why we have RoR); however, Struts strictly implements the MVC model 2 pattern and hereby makes itself powerful for large systems. Everyone can make up his/her own style at this point. Therefore, the holy war on the coding/design style is similar to choose between apples and pears—it’s not necessary to gauge which one is better, as they are just different fruits from different genesis.

4) Although there might be some rule of thumb to write beautiful code, there is not a unique standard.

As I’ve mentioned before, there is no unique standard in coding/design style as you can always attack the same problem in different approaches. This statement not only holds for the coding style, but also for the XML configuration file style and other design-related stuff. For example, when I was learning the Apache Ant, I would like to call the build.xml as makefile.xml or to have separated XML files for each target, etc. However, it is hard to tell which design is better. In the IME case, the programmer simply uses Chinese as the tag name in the XML file. As you might know, as long as the XML is encoded in UTF-8, it is an issue in neither understanding nor program migration. However, this design was criticized for “not very i18n”. I would say that this judgment is goofy and absurd.

5) Stay foolish

As it is usually hard to define which style is better, the developers in the open source community should indeed stay foolish. I do agree that arguments and the discussions towards a particular project are quite helpful. However, keep this discussion in a polite and elegant way would be more productive.

6) Never judging people by their code style.

Because this doesn’t make any sense. In the book “12 habits that hold good people back”, the author mentioned a kind of people who “see the world in black and white”. One who simply judging person by the coding style falls to this category. Coding style is not the whole part in programming. Moreover, a poor coding style/design does not necessary means the lacking of ability in developing the system.

7) Refactory is a procedure, not a purpose.

Just like Feynman’s famous quote that “physics is like sex”, refactory of the code is just like sex too. Although it may give some practical results, but that’s not why we do it.

In short, refactory is a procedure that makes the code more readable or easier to maintain. However, there is not reason why we should refact the code solely for the aesthetic purpose. I can image that the GoF’s book will boost a passion from the bottom of the hearts of the readers to refact every piece of code written by others. I was one of them. The GoF’s book will definitely help build a “sensitive nose” that can sniff the smell of the code. Probably applying a nice coding style or design pattern is a good practice. I still insist that a nice coding style or sophisticate design pattern is not the reason why we write code.

8) Efficiency or beauty is an issue, but making it workable is the first priority.

When I was interviewed with Google, one of the interviewers gave me a very good suggestion when I got stuck in a problem. He told me that the philosophy at Google is “first make it work, then improve it”. In the open source community, usually the software is for solving a real world problem. Therefore, making it work is much more important than making it beautiful. I have to concede that there are some developers who can achieve both goals in the same time. Nevertheless, for most developers, usually the code is ugly and awkward at the very beginning. If I have to choose in between a piece of workable but ugly code and a piece of beautiful but malfunctioned code, I prefer the previous one. I guess except the coding-style paranoia, everyone will choose the first one. The truth is (or 80-20 principle tells us that): an ugly but workable prototype will cost 20% of the total time; a pretty and not necessarily workable prototype will cost about 80% of the total developing time. As software is changing all the time, on cannot expect to have a “final” version that is both beautiful and workable. Therefore, to choose workable instead of pretty code is wise.

9) Peer review is about finding the (potential) bug, not about the coding style.

I’ve heard that in many big name companies such as Google, the code peer review plays a quite important role. I’ve also once been an intern at Siemens. There, before checking the code into the code repository, usually a colleague will go though your code to see it there’s something wrong. (Of course you have to pass the unit test before you checking in). According to my experience, peer review is more about the nice practice of extreme programming than the code style exam.

In the open source community, the scenario changes: everyone can read your code and figure out what happens in the code. While the developer should expect the feedback from the community, it should be in the form of suggestion or patches instead of fierce criticizing, especially on the coding/design style. Again I would emphasize that open source community should always be polite to the contributors while cruel to the malicious saboteurs.

10) Instead of to say something, why not to do something.

The best way to contribute the open source community is not to say something, but to do something. For instance, if you feel uncomfortable about one project, then instead of writing a letter to the author complaining about their poor coding style, why not just refacting the code and republishing the code? In my humble opinion, barking dogs seldom bite.