Friday, November 28, 2014

How to Find Missing Number on Integer Array of 1 to 100 - BitSet Example

One of the most frequently asked question on programming interviews is, write a program to find missing number in an array in Java, C# or any other language; depending upon which language you choose. This kind of coding interview questions are not only asked in small start-ups but also on some of the biggest technical companies like Google, Amazon, Facebook, Microsoft, mostly when they visit campus of reputed universities to hire graduates. Simplest version of this question is to find missing elements in an area of 100 integers, which contains numbers between 1 and 100. This can easily be solved by calculating sum of the series using n(n+1)/2, and this is also one of the quickest and efficient way, but it cannot be used if array contains more than one missing numbers or if array contains duplicates. This gives interviewer some nice follow-up questions to check whether candidate can apply his knowledge on slightly different condition or not. So if you get through this, they will ask you to find missing number in array of duplicates. This might be tricky but you will soon find out that another way to find find missing and duplicate number in array is to sort it. In sorted array, you can compare whether a number is equal to expected next number or not. Alternatively you can also use BitSet in Java to solve this problem. By the way, if you are going for interview, then apart from this question, its also good to know how to find duplicate number in array and program to find second highest number in an integer array. More often than not, those are asked as follow-up question after this.

Wednesday, November 26, 2014

Does column width 80 make sense in 2014?

One of the oldest coding practice is to keep line width 80, Why? I believe it was to make your code more readable in the age of small monitors so that whole content can fit in screen, or it might have origin from the age of punch card, which was used to be 80 column wide; but do you think this rule make sense in 2014? We are now living in the age where most of the developers has got large monitors, which can show up-to 180 characters, doesn't this is wastage of precious monitor space? It also make your code unnecessary long, than it actually is. I first come to know about line wrapping at 80, while reading Oracle Code Conventions for the Java Programming Language, which was last revised at April 20, 1999, which under indentation says
4.1 Line Length
Avoid lines longer than 80 characters, since they're not handled well by many terminals and tools.

Note: Examples for use in documentation should have a shorter line length-generally no more than 70 characters.

source : http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-136091.html#248

If I understood correctly (I may be wrong), one goal of this rule is consistency. I used to think that 80 was silly, but being able to go through source code written by a dozen different teams over last 7 years and not needing to re-size my window is a really nice thing. Consistent column width helps with the pace of reading code. Since I mostly worked with large monitor, I also realize that we are wasting lots of precious space. Consistent column width of 80 is simply too little. I personally use 120 unless the project I work already finalized a column width, in that case I go for consistency. One more reason people give for still using column with of 80 is that now days they are working with multiple files at once. For example, if you use standard column width you can fit couple of files across a reason and can compare them line by line, which I believe is real benefit. You can even do a three-way merge inspection on one screen without scrolling sideways. By the way this should not be done at cost of excessive wrapping. I understand that consistent columns make it easier to scan and read through text but it doesn't mater whether it's 80 or 120.
Why standard column width is 80 character, does it make sense



On closing note, I would say that consistency is nice and you must go for it but 80 or even 100 is too short. Many developer could probably live with 120 or even 150 though.  Our modern wide screen high definition LCD monitors can easily handle more. It is much more readable then the excessive wrapping because I personally find it much harder to read a wrapped line than just seeing the whole thing in one line. Of course this is just preference and others will feel different. 

Monday, November 24, 2014

Don't use System.exit() on Java Web Application

I have recently come across a code snippet, where programmer was using System.exit() if application failed to acquire necessary resource after couple of retry. His reasoning was that since, application cannot function, if essential resources like database is not available or there is no disk space to write records in File system. Ok, I hear you; but System.exit() in Java Web application, which runs inside either web server or application server, which itself is Java program is not a good idea at all. Why? because invoking System.exit() kills your JVM, invoking this from Tomcat or Jetty, will not only kill your application but most likely server itself. This can be potentially dangerous, if that server also host other critical application, which is not uncommon at all. As per my experience, System.exit() calls are quite common in overly broad try-catch blocks in web application start-up code that loads environment variables, properties files, connect to MQ Series, establishes database connection, opens socket connections, etc. This is still ok, if you are writing core Java based server, where each application has their own JVM, but with web application deployed on Tomcat, JBoss, WebSphere, Weblogic or any other application server, using System.exit() is big mistake. In worst case can result in outage for lots of other critical application. On the other hand, there are ways to prevent your web application from someone else’s mistake, by enabling Security Manager. System.exit() and Runtime.exit() both goes through the security manager. Enabling Security manager will catch these calls and reduce them into an exception rather than shutting down the whole VM. It's not difficult to enable the security manager in most application servers, Tomcat, JBoss both has documented steps to enable security Manager.