[kepler-dev] Query Builder Code Review

[Rod Spears]

Sorry, I completely disagree. Writing software is certainly not the same 
as publishing academic papers, and I think it is a fascinating thought 
that Open Source could/should be considered a published work (sounds 
like a discussion for another day).

The reality of Open Source software is that if you put a lot of rules in 
place you begin to limit the contributions, and that can be both good 
and bad. There is certainly a desired level of quality and certainly 
rules enforce that etc. etc. It was always a very difficult line to 
walk; that is, to encourage contributions and then figure out "how" to 
accept good work that may not fit exactly into the place it needs to fit.

For example on Mozilla, the lack of every single file, module and/or 
line of code looking exactly the same was never a problem for anyone 
contributing to the project (I can't say it hurt productivity or the 
quality of the code).

This discussion and it is one I have had over and over, reminds me of 
the great commercial software dilemma: Would a software engineer rather 
write:
1) A perfectly engineered piece of software with no bugs, that doesn't 
sell a dime.
2) A rather odd piece of software with some questionable design and 
architectural decisions that sells millions of copies.

Certainly when writing commercial code, productivity ranks up there with 
quality and all the other important aspects of creating great software. 
I have seen this over and over again at the start of every project. The 
engineers wrangle over coding style for weeks, nobody can agree but with 
the higher levels of a style guide and in the end everyone gets worn 
down and tired of the discussion. And then everyone writes their code 
adhering to those general guidelines. I have yet to work on a commercial 
project where the style guide for coding was dictated to the engineers.

But Kepler (with contributions from SEEK) is not a commercial project. 
So I guess I am at a loss to what its true priorities should be. My 
priorities from the beginning have always been to create something that 
people will actually use. To reach that goal I want to be as productive 
as possible.

In my personal opinion the Ptolemy style guide is quite unique and so 
completely different than any other style guide I have used, that I find 
it cramping my style (pun intended). So I did what I did for the sake of 
getting my work done in a timely manner. (I could argue that because I 
used a style guide that is more comfortable to myself, the quality of my 
code is higher than if I struggled to "think" about my code as others 
"think" about their code)

I stand by what I said earlier about a general style guide with module 
ownership and adapting to the style of the owner. It just seems odd that 
I need to adapt to Ptolemy's style guide (which is basically what 
Kepler's style guide is) and I doubt I will ever change a line of 
Ptolemy code. Of course if I did, I would be more than happy to adhere 
to its style completely.

Rod


Edward A Lee wrote:

>
> I would not take lightly making exceptions to the coding style...
> Do it once, and everyone will feel free to do it, and you will not
> have a coding style anymore...
>
> If you are publishing an academic paper, the editors of the journal
> or conference proceedings get to decide on formatting issues. You
> may have strong preferences about font, layout, reference styles,
> header styles, etc., but you are not given a choice.  Should that
> be changed?  I don't think so...
>
> Open source software should be viewed as form of publication.
> The same principle should apply.
>
> Edward
>
> At 01:29 PM 8/12/2004 -0500, Rod Spears wrote:
>
>> I agree that we should have a more "formal" meeting about our Kepler 
>> coding standards. And I agree that one style does not fit all.
>>
>> But I still think we need to have some way to distinguish the scope 
>> of a variable from its prefix. If folks don't like what I have 
>> proposed then pick something, but it can be rather confusing without 
>> a prefix (as I have found when reading some of the current code).
>>
>> As a suggestion consider this:
>> On Mozilla we had a general set of guidelines, which most us 
>> followed, but not everyone unfortunately. Of coarse, we could never 
>> agree on the curly brace issue, but we did a fairly good job on 
>> deciding on file names, interface file names, method argues, class 
>> data member names, and global names.
>>
>> The other overriding rule (especially because we had the notion of 
>> module ownership), was that you were to always make attempt to follow 
>> the coding standard of the files(s) you were working in.
>>
>> Meaning those who spent a lot of time in their modules had a little 
>> more flexibility in the style for those files, thus making it easier 
>> and more natural for those developers. Then, if by chance, you found 
>> yourself making changes to other people's code, you adapted to their 
>> style. The obvious idea was that you probably weren't going to be 
>> doing a lot of editting in other peoples code. Which, as it turns 
>> out, was pretty much true.
>>
>> I don't expect to be editting much if any Ptolemy code, etc. And it 
>> wouldn't make a lot of sense for someone to spend much time in the QB 
>> trying to fix a bug when I should probably be the fixing it.
>>
>> I think there is an economies of scale thing in here somewhere ;-)
>>
>> (Besides, outside of variable naming conventions, a lot of code can 
>> be reformatted with Eclipse or other tools)
>>
>> Rod
>>
>>
>> Edward A Lee wrote:
>>
>>> At 11:17 AM 8/12/2004 -0500, Rod Spears wrote:
>>>
>>>> Also, there seems to be some varying feelings and opinions about 
>>>> the coding style for Kepler. My approach which I am sure differs 
>>>> from Kepler is as follows:
>>>>
>>>> 1) All method arguments start with a lowercase "a"
>>>> 2) All class data members all start with "m" (unless they are final)
>>>> 3) All local variables have no prefix.
>>>>
>>>> It is my belief that you should always be able to look at a 
>>>> variable in the code and understand it's scope. I disagree with the 
>>>> approach where both the method arguments and the local variables 
>>>> have no prefix and are often distinguished by a "this.", which is 
>>>> rather verbose at times.
>>>
>>>
>>> While I think these are valid points,
>>> I would like to make a case for following the coding style anyway...
>>>
>>> There is no coding style that will appeal to everyone (I guarantee it).
>>> The benefits of having a uniform coding style, however, far outweigh
>>> _any_ benefits you might derive from any particular coding style.
>>>
>>> So, I would suggest that the discussion needs to be:
>>>
>>>  1) What changes should be made to the uniform coding style?
>>>  2) Who's going to do the work to convert the existing code base
>>>     to conform with any changes in the coding style?
>>>
>>> Number 2 suggests that changes had better have pretty compelling
>>> reasons... I don't find the above reasons compelling enough...
>>> (nor are they consistent: What if I name a local variable "model"?
>>> Is it a class data member?).
>>>
>>> I think the concerns addressed by this proposal are adequately
>>> addressed by keeping methods short and by choosing readable
>>> names for variables that a compositions of full words and clearly
>>> define the role of the variable.
>>>
>>> Edward
>>>
>>>
>>>
>>> ------------
>>> Edward A. Lee, Professor
>>> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>> phone: 510-642-0455, fax: 510-642-2739
>>> <mailto:eal at eecs.Berkeley.EDU>eal at eecs.Berkeley.EDU, 
>>> http://ptolemy.eecs.berkeley.edu/~eal
>>
>>
>>
>> -- 
>> Rod Spears
>> Biodiversity Research Center
>> University of Kansas
>> 1345 Jayhawk Boulevard
>> Lawrence, KS 66045, USA
>> Tel: 785 864-4082, Fax: 785 864-5335
>
>
> ------------
> Edward A. Lee, Professor
> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0455, fax: 510-642-2739
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>


-- 
Rod Spears
Biodiversity Research Center
University of Kansas
1345 Jayhawk Boulevard
Lawrence, KS 66045, USA
Tel: 785 864-4082, Fax: 785 864-5335

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20040813/03ca7a8a/attachment.htm