Re: Code style
+1 to sharing styles. Next week, I'll see if I can get my Eclipse 3.2 style that I customized to fit Lucene style. Otis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simpy -- http://www.simpy.com/ - Tag - Search - Share - Original Message From: Chris Hostetter [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Saturday, May 19, 2007 2:05:33 AM Subject: Re: Code style : thinking might be useful (in Lucene as well) is to have downloadable : codestyle templates for IntelliJ and Eclipse defined and linked to : from the developer section of the website (or it could even be I certainly have no objection to hosting any style files for any editors people like on the wiki, or even in SVN, as long as it's clear these are just aids for people who want help being more consistent, and not indications that the use of certain editors/IDEs to ensure consistent code are mandatory for submitting patches or commiting changes. -Hoss
Re: Code style
On 5/17/07, Otis Gospodnetic [EMAIL PROTECTED] wrote: Touchy topic: code style Uh, oh... something everyone will have an opinion about ;-) Should Solr be following the Lucene code formatting/style? Lucene follows Sun's recommendation except for the 2-space indent, I believe. Well, that's the general guidelines... there is a ton of lucene code that doesn't follow that though. One violation repeated everywhere is if (foo) bar(); Those don't bother me personally, I'm just pointing it out. I'm asking because Solr is full of variable and method names that look like abbrevs ;) - e.g. getDocListC - C? Heh... I never realized abbreviations were off-limits. In this particular case, I needed to refactor getDocList into a caching version and a non caching version (C) and (NC). , and on top of that the code is rather dense,without,many,spaces, so it's hard to read, at least for me. Spaces between lines, or spaces in a single line? I tend to compress code where the logic is easy to understand... sometimes spreading simple things out make it harder to see everything in context. How do the rest of you feel? I volunteer to tidy up the code, if others agree with following Lucene's formating. I believe Nutch and Hadoop already follow it. Solr already has a policy that is the same as Lucene. I'm fine with cleanups... just try to avoid breaking patches in JIRA. -Yonik
Re: Code style
: How do the rest of you feel? I volunteer to tidy up the code, if : others agree with following Lucene's formating. I believe Nutch and : Hadoop already follow it. : : Solr already has a policy that is the same as Lucene. : I'm fine with cleanups... just try to avoid breaking patches in JIRA. Once upon a time i thought the idea of cleaning up the formatting of code in commits that *only* changed formatting was a good idea ... but even if hte message is clear that it's just a formatting commit, it still creates noise, makes some patches harder to apply, and moves line numbers arround reducing the number of situations where you can make educated guessees about what went wrongwhen looking at a stack trace from someone without knowing exactly which version they were using. I'd certianly prefer if all new code and new changes met teh style guidelines we have setup -- tidying up the lines that are being changed anyway as part of the commit, but frankly i'd just as soon leave code that works but isn't super pretty well enough alone. -Hoss
Re: Code style
Hi, - Original Message From: Yonik Seeley [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Thursday, May 17, 2007 2:05:41 PM Subject: Re: Code style On 5/17/07, Otis Gospodnetic [EMAIL PROTECTED] wrote: Should Solr be following the Lucene code formatting/style? Lucene follows Sun's recommendation except for the 2-space indent, I believe. Well, that's the general guidelines... there is a ton of lucene code that doesn't follow that though. One violation repeated everywhere is if (foo) bar(); Those don't bother me personally, I'm just pointing it out. OG: yes, that's one of those things my brain must have learned to read easily either way. What's missing here? Curly braces? I'm asking because Solr is full of variable and method names that look like abbrevs ;) - e.g. getDocListC - C? Heh... I never realized abbreviations were off-limits. In this particular case, I needed to refactor getDocList into a caching version and a non caching version (C) and (NC). OG: Si, I realized that as I read the core more, but it wasn't obvious to me immediately. How quickly things become obvious is important, I think. , and on top of that the code is rather dense,without,many,spaces, so it's hard to read, at least for me. Spaces between lines, or spaces in a single line? OG: Heh, good question. Again, spaces or not between lines are easy for me, it's the lack of spaces in a single line that make things hard to read-kind of likethings should be made as simple as possible, but not any simpler.-A.Einstein would be hard to read. Mental token parsing - WhiteSpaceBrainTokenizer, I guess. I tend to compress code where the logic is easy to understand... sometimes spreading simple things out make it harder to see everything in context. OG: I agree. This made me learn to appreciate vertically tight code sometimes. How do the rest of you feel? I volunteer to tidy up the code, if others agree with following Lucene's formating. I believe Nutch and Hadoop already follow it. Solr already has a policy that is the same as Lucene. I'm fine with cleanups... just try to avoid breaking patches in JIRA. OG: Right. Right to what Hoss said in his reply, too. OG: Luckily, man patch shows -l or --ignore-whitespace, which might help. Otis
Re: Code style
Hi, - Original Message From: Chris Hostetter [EMAIL PROTECTED] I'd certianly prefer if all new code and new changes met teh style guidelines we have setup -- tidying up the lines that are being changed anyway as part of the commit, but frankly i'd just as soon leave code that works but isn't super pretty well enough alone. OG: That would be ideal. However, sometimes you want to work on the existing code and the hard-to-parse style makes it harder for you to follow and understand the code. I'm facing that now with SolrIndexSearcher, which is what promoted this thread. Otis
