So I was chunking out object code in NetBeans, not convinced that I wouldn't end up scrapping classes...or maybe smooshing their functionality into mulligan stew. But I was in The Zone at the time, so nothing mattered so much as splashing ideas out onto screen. As proof I offer the shocking admission that I actually...sit down and brace yourselves...skipped comments.
It's true. (For context, this is like catching Mom/Dad slipping unwanted broccoli to the dog--just like you did Back In The Day.)
Fast-forward to today, and the saving grace is that each of those classes is but a mere sip of Java--nary enough to dissolve a sugar cube. Translated: I still have some idea what I was thinking. And, so, because I had time to fill while waiting for a known distraction, I took advantage of a NetBeans feature that looks at a function's input and/or output parameters and generates the skeleton of the comments for that function. It's one of those features that I learned about long enough ago that I don't recall where, when or how. Only today, though, did I think to have mixed feelings about it.
IMO, the time when that feature is optimally useful--at least in terms of "flow"--is when you've just written completed the outline of the function in question: List of inputs, output type, and any exceptions (for lack of a better term, errors) it could raise with other functions that call on it. Problem is, in most cases NetBeans picks up on the fact that your function is still incomplete (i.e. hasn't specified the promised value to be returned or contains no code capable of throwing exceptions). That's when the little red exclamation point ("compile error") shows up on the periphery of the user interface, basically sticking something irritating into the corner of your eye. Just like it was intended to do.
And thus the "flow" is ultimately subverted. The red exclamation point tickles away at your eyeball until you've fleshed out the code enough to humor the compiler, which has two potential downsides: a.) The chances of losing the birds-eye view is fairly high, and b.) Writing enough code to humor the compiler is not the same thing as writing complete or true code. Or...you put up with it until you finish that portion, which has two potential downsides: a.) Training yourself to ignore that warning, and b.) Making it that much more difficult to find a real error once all the code has been written (i.e. there's a lot more of it). Or you could just skip commenting until the first draft of the class is written.
Heresy. Blasphemy. Sacriliege. (C'mon, already: Next thing I know, somebody'll say that The Monkees played their own instruments too...)
Anyhoo. Do I have an actual, constructive suggestion for improving this facet the (already quite good) NetBeans UI? Or, better yet, plan to put my bling where my blog is and write a better IDE? Oh, heck no. Left to my 'druthers, I could be trusted to stick to a certain comment format that could then be parsed to generate code-skeletons. It makes a certain sense, pseudo-coding before coding. Unfortunately, that still leaves the compiler--red exclamation point--problem if you jump the shark and punch whatever button generates the function "skeleton." (Then, too, building a feature to my preferences does not put anyone in mortal danger of said feature going viral.)
Rather, the point of this is to drag yet another highlighter tip over the Law of Unintended Consequences. Because, in this case, the outcomes are so mixed that I'm not quite sure exactly what behavior consequences were originally expected. But it's pretty easy to see why some programmers prefer to spend their days achieving gestalt with hardware drivers or databases or in the OSI "seven layer salad" or what-have-you. As inscrutable as such critters seem to non-programmers, they can jump in far more predictable ways than human beings.
