[kepler-dev] Query Builder Code Review

Edward A Lee eal at eecs.berkeley.edu
Fri Aug 13 04:50:20 PDT 2004


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




More information about the Kepler-dev mailing list