Wednesday, April 21, 2004

Code Clean...

On my previous .net project I was working in an onshore-offshore model, with the solution architect being from the client. The project was about a client's product of which 3 versions were already released & for version 3.1 the client had given us some good chunk of work, which we were supposed to develop at offshore. What we had been communicated was that the architect is a perfectionist and does a very thorough code review, reviewing almost every line of code written. Before the project, he had sent us Coding Standards Document and wanted us to folllow the document as closely as possible. Like almost all the developers who fret at documents, I read the doc and though most of the "best practices" looked good to read, I thought they'd be tougher to implement. The guidelines had things like there shouldn't be any dead procedures, variables in the code, no commented code, no class should be more than 5000 lines of code(or some magic number), no method within a class should be more than 250 lines, two methods declaration should be separated by a blank line, no blank lines within a method etc. etc. The logic of these guidelines being that 80% of the times the code is maintained by some one other than the original developer and since most of the time/money is spent on maintaining an application, it makes sense that the developer writes "readable" code. The two things that I found pretty hard to follow in the guidelines were "No commented Code" and "No dead dead", which I guess is problem with most of the developer's code. These problems persist because once the developer thinks that the code is "stable", he is very sceptical about modifying it, this thing comes from the age old adage: "Never change a working code". Now if due to some change in business requirements once the code is stable, the developer has to change his implementation, he will always comment out the older code, just in case the newer code doesn't work or the business requirements are again reverted back to the older one. The problem is even if the newer code works and the newer code is stable, the older code remains hanging in the application commented. I also used to keep my older code commented in my applications, the logic being the commented code is not compiled so it doesnt hurt in anyway...one more developer's problem, most of the time developer's seem to miss the point that most probably someone else would be looking/enhancing/bug-fixing their code. Dead code can also be attributed to the same factor, developer being too weary about changing a stable code. Now that I have been working on another project, I realize the importance of the above guidelines. One of my responsibility was to enhance an existing piece of functionality and the developers who wrote that piece of code had been long gone in search of greener pastures. Just glancing at the code made me fret, one class had nearly 2000 lines of code, of which about 500 lines were commented out(some had comment date of around 2 years back!!) and around 500 lines were dead code!!! So the class was only around 1000 lines, the first thing that I did was remove the commented out code and dead code, which made the code a lot more readable and pretty easy to build upon. I feel writing "readable" code is one of the most important factor for any project to be successful in the long run and believe me it does not take too much of time once you get in habit of writing good quality code.

Monday, April 19, 2004

Thunder over Louisville

This saturday(April 17th) there was Kentucky Derby Festival opening ceremony here in Louisville, its called Thunder Over Louisville(more information can be found at their official website Thunder over LVL. The show starts at 3PM with a 6 and a 1/2 hr air show followed with 1/2 hr of fireworks. The event is in the downtown with fireworks off Second Street Bridge on ohio river. Chhavi had come for the weekend, first we were sceptical abt. where we will be staying as the hotels were really expensive for that weekend(hotels which are normally around 70$ per night had upped their rate to 200$ per night for this weekend!!) but Debbie arranged our stay at her sister's apts at highwood dr(so nice of her!). Chhavi reached here around 10:30 on friday night(United flight as usual was late!), I had booked a cab to goto the airport and the same guy(Mohamed) took us to to the apts. Saturday morning we went for a walk to the Ohio river and the walk was pretty beautiful. We left for the waterfront park(its the best place to view the show) at around 12:30 and reached there at around 12:45(Mohamed came to drop us there..he charged for that ofcourse!). The place was pretty crowded but still we got a very good place to sit, other good thing was that it wasn't cold outside with temp. around 80F! The airshow kicked off at 3, to be honest it wasn't the best air show that you can see..the planes would come after 5 mins gap & weren't doing too many stunts..felt chhavi slept off in between!
Thunder airshow
At 9:30PM the fireworks started and were they awesome? they sure were!! What I had heard was that this show are better than any other firework show in America(some even claim the best in the world!). I haven't seen any other firework show so I can't judge for myself but this one was simply amazing, the best part being the Waterfall, in which the fireworks "fall off" the second st. bridge on to the ohio river like a waterfall. The show ended at 10 and every one(there were apparently more than 500000 ppl) wanted to go home in a hurry, so we called up Mohamed, who told us to walk away from the traffic so that he can pick us up and we walked all the way down to Bardstown Rd.(it was around 4 miles walk!) and then took the cab and reached home at around 12:30AM(not too bad a effort for first timers who had no clue abt the area or the directions!). Sunday we just decided to rest our aching limbs and stayed at home, watched 3 movies: Harry Potter and the Sorceror's stone(chhavi always wanted us to watch this movie together), Full Monty and City of Angels(another chhavi's choice). Full Monty was crap, City of Angels was pretty decent but the best of the lot(chhavi, surprise, surprise) was Harry Potter, the movie is pretty light and I enjoyed it till the end. In the evening we went for a walk just around the apts. and it was so full of greenery that we both just fell in love with the place. Monday morning dropped chhavi at the airport and came back to work, it was a pretty hectic weekend for both of us but worth every pain.
Thunder over Louisville Rocks!

Monday, April 12, 2004

Console app in VB 6.0

Recently we had a requirement where vb apps need to be compiled as console applications, so that they can be executed by a java application. The success or failure of console vb app where to be notified by returning th exit code. Returning the exit code wasn't tough, you can make use of ExitProcess API to return the exit code. The problem with ExitProcess is that if you call it within the VB IDE it closes the entire VB. So we used the Debug.Assert hack in the module to figure out whether the app is running in IDE or not. Everything was going on well, till one fine day I decided(can't stay out of the trouble!) that we need to make the application more "OO" and hence thought of moving the console helper module(the module contained ExitProcess and support for ConsoleWrite and ConsoleRead) to a COM dll. So created a dll, included the module and added a wrapper class module, which would just delegate the call to the bas module. The first problem that I faced was figuring out whether the app is running in debug mode or compiled mode. Debug.Assert won't have helped, as the dll was always compiled and compiling the dll removes all Debugging code. As I have learnt in my life as a programmer, when in doubt turn to google, and guess what? found a link to vb2themax article which solved the exact same problem. So included that piece of code and everything went fine except whenever an app would call ReturnExitCode on my consolehelper dll, it would crash with a "Stack Overflow" exception. After coupla hours of debugging figured out that there is a bug in VB compiler(or so I would like to call it!!), if you have two methods with the same name & same signature one in a bas module and another in the class module, the compiler compiles the dll without any complaints. In my dll, I had included the bas module which had a public method "Public Sub ReturnExitCode(byval ExitCode as long)", and I had copied-pasted(the same ol' programmers habit!!) the same method in the class module. The code in my class module was like:

Public Sub ReturnExitCode(byval ExitCode as long)
If Not InIDE Then
ReturnExitCode ExitCode '''this call was supposed to be made to the method in bas module
End If
End Sub

Obviously the code goes into endless recursive loop and throws a stack overflow error. I know it was oversight on my part but still feel vb compiler shouldnt have allowed having two methods with same signature at first place. The fix was pretty easy, rename the method in bas module to something (I chose ReturnExitCodeInModule!). Problem solved, should have relaxed after that but as they say a solution is mother of every new problem...
we had been converting the apps to console application by running EditBin.exe after the app was compiled, so I thought that it would be great if we could compile apps to console application directly from vb compiler. My first thought was to use one of the available add-ins like the one on powervb.com, but that wouldnt have been any challenge for a programmer like me :-) so decided to go Bruce McKinney's way(btw, mcKinnery is the author of oh so famous Advanced VB 5), hence I created my own Link.exe, all that would do is interecept the command line parameters sent to it by VB Compiler, change the /SubSystem:Windows switch to make it /SubSystem:Console and then shell the original Link.exe with this tweaked cmd line params. Guess what? works like a charm, another problem solved i.e. birth of a new problem! now all the applications are compiled as console applications, so how do you compile normal windows apps?? one way to beat it was only if the app references the consolehelper component, my custom linker should tweak the command line else it should pass it on to the vb link.exe untouched(I know it makes the implementation very specific to my needs but hey I never wanted to make my custom linker a commmercial product). But to the linker vb only passes the obj file names & not the references, tried custom C2.exe but that didnt help either, looks like vb compiler itself takes care of references et al(which makes sense), 2 days gone and am still looking for the solution so that I can then concentrate on a new problem.

Getting started...

Have been thinking about blogging for long time but guess have been too lazy(as usual!) to get started till I saw blog of one of my ex-colleagues(Avinash: no prizes for guessing who it is.) So thought of writing anything and everything that comes to my mind and post it here. The posts could be technical or just some stuff about life in general...so watch out...