Re: coding style: this.field



On Fri, 2005-04-29 at 11:43 -0400, Colin Walters wrote:
> On Fri, 2005-04-29 at 11:36 +0200, Alexander Larsson wrote:
> > Whats up with the random uses of this.field that the code seems to be
> > full of? Sometimes its nice in constructors because you want to have
> > parameters with the same name. But why use it elsewhere, when there is
> > no need for it?
> 
> I dunno, I just think it makes things clearer.  At least Eclipse does
> warn you if you do like foo = foo.  If someone wants to say it's one way
> or the other that's fine by me.

Eclipse also colors references to class fields differently than locals,
so you can see such issues if you notice the colors.

> However as far as coding style is concerned, I think we have a much
> bigger problem on the web client side.  Particularly for CSS class
> names.  topic.css is a terrible mess; there's no consistent mechanism
> for figuring out which classes and ids correspond to which elements in
> the UI.  This is something we'll want to change often I think.
> 
> My suggestion here is: If the element is generated by a JavaScript
> class, prefix the element with <classname>, so we might have:
> ClosedCommentCloserPerson.

Yeah, the client side also very much needs a coding style cleanup... I'm
all for using StudlyCaps everywhere, even in the css.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a suave Jewish shaman with a robot buddy named Sparky. She's a 
strong-willed Bolivian archaeologist with the power to see death. They fight 
crime! 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]