Symphonious

java.net blogger Malcom Davis comments on why you should use the Sun Java coding style. The first comment is the perfect example of “ego” that he talks about:

Why not adopt the Sun coding conventions? Simple - because they are derived from an antiquated and BAD way of coding.

There are very good reasons why C programmers moved away from the coding styles used by Sun, and the excuse that ‘modern IDEs have code colouring and brace matcing, etc.’ is NOT a good reason to have to rely on it.

Gah! Could there be a more reactionary, inflammatory and unsubstantiated comment? How does the poster know what the Java coding convention was derived from. What makes it “bad”? Why is an antiquated coding style not a good thing? Why exactly did C programmers move away from the coding styles used by Sun? What evidence is there that C programmers actually did start of such a coding style and move away from it? What problem does code colouring and brace matching supposedly not overcome?

In other words, why should I believe some random comment on a web page which provides no solid argument, no reasoning, no attempt at justification and absolutely no facts? As Malcom noted:

It’s interesting how much an ego can get in the way of being a better programmer.

Indeed.

My house mate informed me this afternoon that the land lord would be coming around tomorrow for an inspection. Hilarity is currently ensuing.

It random matters of interest: This was interesting - living muscle tissue powered nanodevices - and I was always told to think big….

ant has proved itself much easier to set up multiproject builds than maven which is kind of unfortunate since maven forces you into performing multiproject builds quite a lot. Might have to create a decent maven plugin to handle multiproject builds automatically instead of manually having to set up the reactor. Combining the generated website and producing a combined distribution seems to be the key to this.

Obfuscation is evil. I spent all day trying to get it to work for me. Stripping out unused classes (including in dependant libraries) automatically is also evil but not quite as much so. Someone really needs to slap proguard and retroguard around a bit to share some features. Currently proguard has a brilliant config file syntax but renders itself completely useless due to the fact that it can’t handle resources correctly while obfuscating (still good for jar shrinking though) - retroguard on the other hand can’t handle SomeClass.class syntax (which proguard can) and has an awful configuration file syntax (no wildcards). I had to write an ant task to automatically list all the classes in org.apache.xerces since it really doesn’t like being obfuscated. For the record, we obfuscate whatever we can because it noticably shrinks the resulting jar file size by changing things like MyVeryLongMethodName to a. Think of it as lossy compression for java classes.

Tomorrow I plan to spend most of the day swearing about a bug which is causing our applet to stop repainting after a certain point in time. We only managed to reliably replicate it this afternoon and the process of replication is still pretty difficult.

On the plus side, we’re still on track to release the product last Friday. :S