--- On Sun, 4/12/09, Peter Becker <[email protected]> wrote:
> From: Peter Becker <[email protected]> > Subject: [The Java Posse] Re: Code definition > To: [email protected] > Date: Sunday, April 12, 2009, 1:12 AM > Alexey Zinger wrote: > > --- On Fri, 4/10/09, Dominic Mitchell > <[email protected]> wrote: > > > > > >> From: Dominic Mitchell > <[email protected]> > >> Subject: [The Java Posse] Re: Code definition > >> To: [email protected] > >> Date: Friday, April 10, 2009, 11:35 AM > >> On Fri, Apr 10, 2009 at 10:20:32AM -0400, Robert > Hanson > >> wrote: > >> > >>> Every Perl program I have ever written falls > into that > >>> > >> category. Six > >> > >>> months later I can't even figure out how > it works. > >>> > >> Believe me, Perl isn't unique in that > category. > >> There's a *lot* of > >> really incomprehensible Java out there. Sure the > >> individual lines might > >> be readable (if you're lucky) but the program > as a > >> whole is unreal. > >> > >> -Dom > >> > > > > Unless I'm in a real time crunch, I try to step > back after getting the first working version of something > and look over what I just wrote. If I see something > that's gonna be confusing later (weird work-arounds, > subtle diversions from familiar patterns or conventions, or > techniques I use very rarely), I simply write comments. > I've found certain things to come up time and again that > require explanation, where the source is not expressive > enough for a casual code reader. Regular expressions are a > common case, especially in Perl, where they are often not > accompanied by expressive variable names (99% of the time a > good example of what you're trying to match does the > trick). In Java, I've lately found some hidden traps in > using GWT, where what looks like good Java will break or > have unexpected behavior or performance. Comments are your > friend. > > > It sounds like the type of comment I consider a code smell. > If you need > to explain what your code does it might be time to refactor > the code > into something legible. Of course there are exceptions, > e.g. if you need > some stunts for that last bit of performance (assuming you > need that > last bit of performance in the first place), but in most > cases I get > suspicious if I see code with a lot of inline comments. > > But I guess to some extent it is a matter of style and also > how much you > are allowed to dig in and change the whole code to > something different. > > Peter Call it what you wish, but I think of it as a situation, where I am taking a step in the direction of obscurity for some specific reason (to me, it's not always a bad reason) and compensate for it with clear and concise comments. I think it's just realistic -- you can't expect every single API or your own line of code to be completely self explanatory. It's just a fact of life. I just looked up some regex examples and came across this: (19|20)\d\d[- /.](0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01]) Would you prefer to see this in your code with no explanation, or a little line that tells you it's a date matching pattern, or better still, gives you a pseudo pattern or an example of what's expected to match? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
