[seek-dev] Re: [kepler-dev] Query Builder Code Review

[Rod Spears]

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
> 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/seek-dev/attachments/20040812/bdb43aa6/attachment.htm