Ok, here is my 0.02 although I strongly agree with Martin that there a many many many other questions and issues to solve, that deserve our energy and work mania more than this underscore thingy.
* I have heard two real pro arguments from Adam that need not (but could!) help other people read someone else's code easier and prevent from risky and difficult to find errors when someone forgets the "this." in a place where it should be. * Cons? What is a real con argument? Some people find it ugly? Sun said so in 1999? No objection against a new coding convention voting in general. But I have a feeling that we might soon end in deadlock situations. And please please please: Let us do our homework first: Release, TCK testing, Homepage, ... Thanks, Manfred On 2/18/06, Adam Winer <[EMAIL PROTECTED]> wrote: > On 2/18/06, Volker Weber <[EMAIL PROTECTED]> wrote: > > Hi, > > > > we have currently different code styles applied: > > There are many classes in tomahawk which don't prefix private fields > > with '_'. > > Tobago don't use the '_'. > > Haven't looked into adf yet. > > > > I don't think we should stick with what we *most* have (has anyone > > counted what we have most, including adf and tobago?). > > > > Is there any actual reason prefixing private fields with '_'? Any active > > developers using vi? > > We've done it on the ADF Faces source code for ages, > and VI has nothing to do with it - it has everything to do > with making it very easy to read someone else's code and > understand it as quickly as possible. Using "this." > when there is a local variable with the same name is > a hideous convention - unless you *always* use this. to > access an instance variable, whether or not there is a > conflict. That's because when you look at a block > of code, you have no idea what's a local variable and > what's an instance variable without re-scanning the code. > > I've never given much of a whit for the Sun coding standards - > they're largely based on the K&R C coding style (Kernighan > and Ritchie, and I'm dating myself here I know), which was > an attempt to save as much space as possible on 80x24 > terminal monitors. We don't use 80x24 terminals anymore. > > > Why don't have a codestyle which came as near as posible to the personal > > preferences of *most* developers? > > > > BTW: I prefer to have public in interfaces, and i dislike opening braces > > on newlines. > > I like opening braces on newlines, as it makes it much easier to line > them up mentally. I've never heard a reason for keeping opening > braces on the same line other than "it saves space", which isn't > much of reason with today's monitor sizes. > > -- Adam > > > > > > Regards, > > Volker > > > > > > Martin Marinschek wrote: > > > I'm having a good laugh here ;) > > > > > > It's interesting how long we can keep ourselves busy with something like > > > that. > > > > > > For the interested - a short history of the "_" in MyFaces: > > > > > > MyFaces was originally started as a project for an inhouse-application > > > of the OeKB (http://www.oekb.at), and the OeKB has this internal > > > code-style rules which prescribe an "_" in front of private fields > > > (yes, exactly for the VI-editor users under the OeKB developers, yes, > > > there are still some ;). Now when the project went to SourceForge, no > > > one did take the time to change this, and when we went further to the > > > ASF, no one thought about that as well. > > > > > > So this is why we have this _ in place right now - as my most > > > preferred IDE (IntelliJ) copes with this real well (you change a > > > setting, and you have _ support in place), this is not a religious > > > thing for me. > > > > > > I don't have a problem if someone goes through all the code and does a > > > clean-up - but do we really want to do that? > > > > > > Bernd - even though you're disappointed - would you really take the > > > time to clean that up? > > > > > > Wouldn't be too easy, right? > > > > > > regards, > > > > > > Martin > > > > > > On 2/18/06, Bernd Bohmann <[EMAIL PROTECTED]> wrote: > > > > > >>Why we should stick with the '_'? > > >> > > >>The Apache Code Style is the Sun Code Style without allowing tabs. > > >>MyFaces is the first project that used the '_'. (so far I can see) > > >>The Sun Code Style doesn't allow the '_'. > > >> > > >>And I would never accept code without braces. > > >> > > >>Sean Schofield schrieb: > > >> > > >>>Since most of the code in myfaces right now also uses the '_' I think > > >>>we should stick with it. > > >>> > > >>>Everyone needs to keep in mind that the final code style that we come > > >>>up with is not going to be the same as your personal preference or > > >>>what Sun says is the "right way." There is an overall style to *most* > > >>>of the code and we need to stick with what we started. > > >> > > >>XXXXXXXXXX > > >> > > >>Why should the code style doesn't fit with my personal preferences and > > >>what is wrong with the Sun way? > > >>Why we need stick? Are you using vi? > > >> > > >> > > >> > > >>>So lets document the standards and make sure everything from this > > >>>point on conforms to those standards. Ideally the standards won't > > >>>differ much from what we already have. > > >>> > > >> > > >>The current MyFaces codestyle is very ugly. > > >> > > >> > > >>>Again, the "_" is not my personal favorite but it is the standard and > > >>>it has the added bonus of matching up with the ADF stuff. So lets > > >>>stick with it. > > >> > > >>What is about the tobago stuff? Have you ever looked at the tobago code? > > >>You don't like the tobago code style? > > >> > > >>>Sean > > >>> > > >> > > >>I'm very disappointed > > >> > > >>Bernd > > >> > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > > > > Your JSF powerhouse - > > > JSF Consulting, Development and > > > Courses in English and German > > > > > > Professional Support for Apache MyFaces > > > > > > > -- > > Don't answer to From: address! > > Mail to this account are droped if not recieved via mailinglist. > > To contact me direct create the mail address by > > concatenating my forename to my senders domain. > > >
