Agreed. But there is such a thing as great completely uncommented code!

Because of the sort-of-poor English I can't tell if he was kidding or not.

This:

Seems horrible and inexcusable.

i would say i have an above average knowledge of poker history, but i'm not sure what you mean. are you just saying that you're old and live in LA so A-5 lowball and player-dealt 5cd with a bug, all minbet?

You've been around for a while. Do you remember the go-to books, even suggested in the forum sticky, was TJ Cloutier and Ciaffone? Most people started up with Limit then moved over to NL, if my recollection is correct.

I definitely started with Limit, but I like to play both forms. I also started up playing live poker, so I was there when NL games in Commerce were mostly dry, then saw the fairly sudden shift to NL explosion. Just about everyone I played NL with back then were either old leather-asses who played lots of tourneys or they were freshies who learned from Play Poker Like the Pros. Good times.

Did anyone else play Commerce 9/18 and 15/30 back when they had those games on the risers?

Now that I think of it, I'm pretty sure _dave_ plays Stud or Omaha.

Thanks! I started reading "Professional Android 4 App Development" 2 days ago and I'll check out the resources from that blog post. The "Smashing Android UI" seems especially interesting, since I find a lot of the apps on the market quite ugly. :-)

Actually commenting code has been found to have negligable impact on productivity in various studies. What impacts productivity a lot is good names and encapsulation.

The major problem with comments is that they're not maintained that well. Code changes but not the comments. Maintaining comments does add an extra level of effort the where the payback appears to be little if any.

I'm going to be hiking up Mt. Harvard with some guys from work that weekend. Or I should say, I'm going to be dropped by everyone on the hike and hope to make the summit before they get bored and go home. 6 miles and 4500 feet of vertical to the top. I'm still gravities bitch.

The fact that you played the right SF character would already earn you bonus points. I did however play with the Penguins (NHL93=one of the best sports games of all time ldo)

On an unrelated note since I'm considering the idea of a startup after the PhD I have read up on all the lean mumbo-jumbo so if anyone wants to talk about that let me know. I prepared a presentation that I held at a startup information thingy a couple of days ago (it's in German though so not much use for any of you I suppose)

I feel like hands on experience and talking to actual people running businesses would help me quite a bit. I'll do free consulting (aka I'll just spout out whatever I think about your ideas etc) as long as I don't have to sign any NDAs or similar nonsense.

---- poker talk
First poker book I ever read was limit holdem (Sklansky's Advanced player) which obviously drove me to this site (great x-marketing, well done). Only limit I ever played were just for fun donkaments and the like. Very short SNG period -> cash

TJ Cloutier inadvertently helped drive me to 2p2; I read his NL book and Small Stakes Hold-em back to back and already knew enough from math + Magic: The Gathering to realize what a disparity there was.

I once defended one of the TJ Cloutier NL books against someone telling me that it was terrible. I wish I could go back in time and kick my ass.

I started playing 2/4 limit live. I had a sick run of good luck and quickly moved to 6/12 limit where I realized that limit blew and switched to NL. I remember the first time I played NL and some idiot got all in for like 200 BB preflop against my AK with something like A7. Those were the days.

I comment major blocks for the functionality they cover. IE - one little comment like "// filter bar" at the top of a block - makes it a lot easier to find the functionality I need when I just need to fix some little bug later. I also comment anything that's counterintuitive or can't be explained by the method name. Obviously you try to avoid counterintuitive code, but that's not always 100% possible.

My test is, if I come back in six months – am I going to spend a lot of time confused trying to figure out what this does. If so I leave one to make things even easier on myself (or whomever has to look at the code).

Every good programmer that I know does this. I agree too much commenting can be counterproductive, which is why possibly some studies came to the conclusion that commenting overall is a wash, or slightly counterproductive. But I know that good succinct comments help.

I wonder if it might actually be a good idea to explain your code to that rubber duck and not just rely on it for debugging.

I know its just an example, but "filter bar" is the type of comment that I think is often worthless. I find too often people explain 'what' code does - which can often be done better just by writing good code (like calling your method filterBar()). And aside from often being extraneous 'what code does' comments can easily become 'what code use to do but doesn't anymore' comments.

Obviously, I still comment any code where it isn't entirely obvious what its doing. But most of my comments are explaining 'why' I'm doing something - "reload this object because it may have changed underneath us and we need the latest values" or are usage comments "Returns 0 if variable bar is null".

When you have 4 or 5 sections like filter bar, option bar, infinite grid, carousel etc. - it never hurts to call that out so me or someone else in the future doesn't spend 5 minutes figuring out which block they should work in. The filter bar block is never going to magically change to something else.

I'm skeptical of the results of a study being useful here. The reason is that probably 90% of comments are pretty useless like this:

So if you're using a naive measure like total number of lines that are comments then the code with tons of useless and overly verbose comments may indeed wind up with lower quality overall.

But the 10% of useful comments are very helpful in my experience. Comments can be the difference between a cryptic "WTF why is this line in here" reaction and "oh, this strange line is a fix for bug X, that makes sense"

If only there were some method of dividing up code into easy to read blocks...

ballin - that's a perfect example of the kind of comments that I'm calling useless.

As did I.

But we can never briefly label what each block does - that violates code purity. Or something.

Well to be fair comments like that are usually written for document generators.

Personally I hate filling out JSDocs even with decent support from your editor but they are a good option to use if you want "compile time" type hinting and auto generated documentation.

Document generators can generate just as useful documentation from a method like:

Most of my comments are in the vein of "there's probably a better way to do this that I should really come back to and review but that sounds like work and this has to get done".

I've worked with people that would argue that if you have a block of code that needs a description for what that block does it should absolutely be a separate method. While I'm not that strict I do think its a rare exception that you have a block of code that is all of:

* Simple enough that it doesn't need to be extracted into a separate method
* Complex enough that it requires a high-level comment
* Part of a method that isn't already too big and should be broken up anyway.

Maybe in a statically typed language. I mentioned JSDocs for Javascript specifically, since JSDocs tend to have types added in too.

A lot of people like to see short descriptions for each argument too when skimming the docs. Often times it's useless but sometimes it's not. If your company uses a certain rule set for doc generation you would end up following the guidelines for both obvious and non-obvious arguments.