topcoder dev



All timestamps are based on your local time of:

Posted by: stak
Posted on: 2006-10-26 20:17:20

last thursday, i decided to try out one of topcoder's development contests. (i'm not sure how many of these links you'll be able to access unless you're logged in to topcoder, but i'll keep linking anyway). the contests are posted every thursday, and submissions are due the next thursday, hence my non-posting for the last week.

i spent pretty much all my spare time for the last week working on the Sliding Tile Puzzle 1.0 component. it took me only a couple of days to get to being functionally complete; the rest of the time was spent productizing it to the standard that they require. even so, i don't think my final submission will pass their screening. the overhead that goes with the code is just too high.

documentation was a big sticking point. i hate documenting my code - more so than other people, i think. in the actual production code files (i.e. not including unit test files), there were 3570 lines; 1873 of these lines were javadoc, and an additional 407 were blank. that leaves only 1290 lines of actual code. i would guesstimate that around 20% of that was just error-checking and input validation, a lot of which would have been unnecessary with a slightly better design. the unit test files were another 1695 lines in all.

i understand most of this stuff is actually useful to them, since it's almost guaranteed that the same developer will never come back to make revisions to the code, so they need it to be properly documented and have a regression test suite. but it's still a pain in the ass.

there were other things that annoyed me, and that i think are preventable. the design documentation comes in a poseidon zuml file, and (almost always, according to the forums) generates incorrect stubs. it took me a while to get the stubs working, and i had to basically go over every public class, method, and variable and make sure it was generated properly.

bad class/variable names was another big problem; i've griped about this before. they don't use hungarian notation, but their variable names were just as fugly. if all the code is in located in the com.topcoder.util.puzzle.slidingtile package, is it really necessary to prepend "SlidingTilePuzzle" to the beginning of each class name? it's kind of redundant, specially when the style guidelines disallow block imports; you have to import each class individually, so it's pretty clear where they're coming from.

the long class/variable names had a cascading effect with the 120 characters-per-line limit and javadoc - the line limit caused the code to wrap a lot, and combined with the javadoc, made everything very vertically spaced out. i think this is the first time in my life i've dealt with code that actually *requires* dual 21-inch LCD flat panels à la googleplex to be nicely viewable. i hate it when functions are longer than a screenful, since it becomes exponentially harder to grasp when you have to constantly page up/down to see the whole thing.

as you might have guessed, i also have issues with their style guide. for the most part it follows sun's java coding conventions, so it's not too bad. the bad part is how they enforce it. there's a program called checkstyle that you can run that will spit out a list of all the style errors. it takes a configuration file, and topcoder provides this on their website. there's another program called jalopy that will try and reformat your code. it also takes a configuration file, and topcoder also provides this on their website. you'd think that if you ran jalopy on your code, it would reformat your code in accordance with their style guidelines, and checkstyle wouldn't complain. you'd think.

on top of everything, my internet died yesterday, so i had to grab the midnight bus to the university to submit the code. i ended up fixing more style issues while wireless-ing in the CPH foyer, finally giving up at 3am with over 100 style warnings, and just submitted what i had. the sample review scorecard doesn't give style too much weight, but it does seem kind of strict in the wording, specially given their tools don't work as advertised.

wow, that was a long rant. but as further justification that this is a systemic problem, and not just me whining about things, only 5 of the 22 registered competitors actually submitted anything at all.

Posted by Dmitry at 2006-10-27 01:38:00
Hey Kats,

Andrew started a dream blog!!!
http://adhoo.blogspot.com
He's ashamed to tell anyone about it.
[ Reply to this ]
Posted by stak at 2006-10-27 07:49:23
Hehe.. that's awesome :)
[ Reply to this ]
Posted by Lin at 2006-10-28 13:45:04
Exactly how do these competitions work? Who judges what?
[ Reply to this ]
Posted by stak at 2006-10-28 15:59:28
well, the component development contests are judged by a review board of (i think) 3 people. they each fill out the review scorecard independently, and then you get the average of the three. if you feel they misunderstood something, you can appeal stuff and get things re-evaluated, but that's mostly it.
[ Reply to this ]

[ Add a new comment ]

 
 
(c) Kartikaya Gupta, 2004-2025. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!