[seek-dev] Re: [kepler-dev] Query Builder Code Review
Bertram Ludaescher
ludaesch at sdsc.edu
Sat Aug 14 16:17:14 PDT 2004
>>>>> "RS" == Rod Spears <rods at ku.edu> writes:
RS>
RS> Sorry, I completely disagree. Writing software is certainly not the same
RS> as publishing academic papers, and I think it is a fascinating thought
... one of the major differences being that you can actually do
something with software ;-)
Yes, they are different, but there is value to both and the difference
is not as large as you may think. In some (life science) domains,
publishing a paper is almost tantamount to uploading a dataset (having
the experimental data, information about the protocol etc). The paper
really just means to cut down a bunch of trees to produce paper that
holds the long list of authors (all the students, postdocs, and last
not least the lab director/PI ;-), plus of course the reputation of
the journal -- which ultimately comes from the community itself.
I like the idea of publishing working software alongside with the
academic paper. Just as biologists are being forced to back up their
claims and experiment outcomes by uploading/linking their data to
known repositories (eg PDB) before the paper can get published in a
certain journal, some branches of the computing world might think
along similar lines. This will not apply to every branch of CS, but
for some it might make sense
RS> that Open Source could/should be considered a published work (sounds
RS> like a discussion for another day).
yeah
As for the discussions on the coding style: I think I can see were
both sides are coming from. I've heard developers say that the PTII
coding style rules are quite non-standard and that may very well be.
(even taking into account that there are different standards).
At the same time we should remember that Kepler is really Ptolemy ++ X
where X are the various wild ideas that we come up with in the context
of scientific workflows. There is certainly great value in staying
close to Ptolemy and having some (or many) things picked up as part of
Ptolemy. We have seen by now several examples were work and ideas from
Kepler directly or indirectly influenced Ptolemy thinking and led to
code being produced in Ptolemy.
So while you might not write Ptolemy code directly, writing more or
less Ptolemy "conformant" Kepler code will increase the chance of
Ptolemites (or Keplerites who think like Ptolemites... the
intersection is not empty) looking at the code, providing feedback, or
even incorporating it.
But by the nature of things, we will not always agree.
If the cost for developers is really too high (let's quantify that) to
adopt those rules, then maybe we have to live with the suboptimal
solution of having two styles (please not more than that..).
Concurring with Edward in his follow up, I think the real challenge is
not in the coding style (hey, aren't there tools that "fix" at least
the layout style or create different "views")?
It's in the abstractions that we devise (e.g. via semantic
types.. making Shawn a Keplerite soon, or the original Ptolemy idea of
separating actors from directors, or having composite actors, or
having mobile code etc etc) it's these abstractions and new ones that
will help organize actors into meaningful libraries that work together
at the level the scientist (or the engineer) find useful..
Bertram
RS> The reality of Open Source software is that if you put a lot of rules in
RS> place you begin to limit the contributions, and that can be both good
RS> and bad. There is certainly a desired level of quality and certainly
RS> rules enforce that etc. etc. It was always a very difficult line to
RS> walk; that is, to encourage contributions and then figure out "how" to
RS> accept good work that may not fit exactly into the place it needs to fit.
RS>
RS> For example on Mozilla, the lack of every single file, module and/or
RS> line of code looking exactly the same was never a problem for anyone
RS> contributing to the project (I can't say it hurt productivity or the
RS> quality of the code).
RS>
RS> This discussion and it is one I have had over and over, reminds me of
RS> the great commercial software dilemma: Would a software engineer rather
RS> write:
RS> 1) A perfectly engineered piece of software with no bugs, that doesn't
RS> sell a dime.
RS> 2) A rather odd piece of software with some questionable design and
RS> architectural decisions that sells millions of copies.
RS>
RS> Certainly when writing commercial code, productivity ranks up there with
RS> quality and all the other important aspects of creating great software.
RS> I have seen this over and over again at the start of every project. The
RS> engineers wrangle over coding style for weeks, nobody can agree but with
RS> the higher levels of a style guide and in the end everyone gets worn
RS> down and tired of the discussion. And then everyone writes their code
RS> adhering to those general guidelines. I have yet to work on a commercial
RS> project where the style guide for coding was dictated to the engineers.
RS>
RS> But Kepler (with contributions from SEEK) is not a commercial project.
RS> So I guess I am at a loss to what its true priorities should be. My
RS> priorities from the beginning have always been to create something that
RS> people will actually use. To reach that goal I want to be as productive
RS> as possible.
RS>
RS> In my personal opinion the Ptolemy style guide is quite unique and so
RS> completely different than any other style guide I have used, that I find
RS> it cramping my style (pun intended). So I did what I did for the sake of
RS> getting my work done in a timely manner. (I could argue that because I
RS> used a style guide that is more comfortable to myself, the quality of my
RS> code is higher than if I struggled to "think" about my code as others
RS> "think" about their code)
RS>
RS> I stand by what I said earlier about a general style guide with module
RS> ownership and adapting to the style of the owner. It just seems odd that
RS> I need to adapt to Ptolemy's style guide (which is basically what
RS> Kepler's style guide is) and I doubt I will ever change a line of
RS> Ptolemy code. Of course if I did, I would be more than happy to adhere
RS> to its style completely.
RS>
RS> Rod
RS>
RS>
RS> Edward A Lee wrote:
RS>
>>
>> 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
>>
RS>
RS>
RS> --
RS> Rod Spears
RS> Biodiversity Research Center
RS> University of Kansas
RS> 1345 Jayhawk Boulevard
RS> Lawrence, KS 66045, USA
RS> Tel: 785 864-4082, Fax: 785 864-5335
RS>
RS> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
RS> <html>
RS> <head>
RS> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
RS> <title></title>
RS> </head>
RS> <body bgcolor="#ffffff" text="#000000">
RS> Sorry, I completely disagree. Writing software is certainly not the
RS> same as publishing academic papers, and I think it is a fascinating
RS> thought that Open Source could/should be considered a published work
RS> (sounds like a discussion for another day).<br>
RS> <br>
RS> The reality of Open Source software is that if you put a lot of rules
RS> in place you begin to limit the contributions, and that can be both
RS> good and bad. There is certainly a desired level of quality and
RS> certainly rules enforce that etc. etc. It was always a very difficult
RS> line to walk; that is, to encourage contributions and then figure out
RS> "how" to accept good work that may not fit exactly into the place it
RS> needs to fit.<br>
RS> <br>
RS> For example on Mozilla, the lack of every single file, module and/or
RS> line of code looking exactly the same was never a problem for anyone
RS> contributing to the project (I can't say it hurt productivity or the
RS> quality of the code).<br>
RS> <br>
RS> This discussion and it is one I have had over and over, reminds me of
RS> the great commercial software dilemma: Would a software engineer rather
RS> write:<br>
RS> 1) A perfectly engineered piece of software with no bugs, that doesn't
RS> sell a dime.<br>
RS> 2) A rather odd piece of software with some questionable design and
RS> architectural decisions that sells millions of copies.<br>
RS> <br>
RS> Certainly when writing commercial code, productivity ranks up there
RS> with quality and all the other important aspects of creating great
RS> software. I have seen this over and over again at the start of every
RS> project. The engineers wrangle over coding style for weeks, nobody can
RS> agree but with the higher levels of a style guide and in the end
RS> everyone gets worn down and tired of the discussion. And then everyone
RS> writes their code adhering to those general guidelines. I have yet to
RS> work on a commercial project where the style guide for coding was
RS> dictated to the engineers.<br>
RS> <br>
RS> But Kepler (with contributions from SEEK) is not a commercial project.
RS> So I guess I am at a loss to what its true priorities should be. My
RS> priorities from the beginning have always been to create something that
RS> people will actually use. To reach that goal I want to be as productive
RS> as possible. <br>
RS> <br>
RS> In my personal opinion the Ptolemy style guide is quite unique and so
RS> completely different than any other style guide I have used, that I
RS> find it cramping my style (pun intended). So I did what I did for the
RS> sake of getting my work done in a timely manner. (I could argue that
RS> because I used a style guide that is more comfortable to myself, the
RS> quality of my code is higher than if I struggled to "think" about my
RS> code as others "think" about their code)<br>
RS> <br>
RS> I stand by what I said earlier about a general style guide with module
RS> ownership and adapting to the style of the owner. It just seems odd
RS> that I need to adapt to Ptolemy's style guide (which is basically what
RS> Kepler's style guide is) and I doubt I will ever change a line of
RS> Ptolemy code. Of course if I did, I would be more than happy to adhere
RS> to its style completely.<br>
RS> <br>
RS> Rod<br>
RS> <br>
RS> <br>
RS> Edward A Lee wrote:<br>
RS> <blockquote
RS> cite="mid5.1.0.14.2.20040813044645.0284aaa8 at mho.eecs.berkeley.edu"
RS> type="cite"><br>
RS> I would not take lightly making exceptions to the coding style...
RS> <br>
RS> Do it once, and everyone will feel free to do it, and you will not
RS> <br>
RS> have a coding style anymore...
RS> <br>
RS> <br>
RS> If you are publishing an academic paper, the editors of the journal
RS> <br>
RS> or conference proceedings get to decide on formatting issues. You
RS> <br>
RS> may have strong preferences about font, layout, reference styles,
RS> <br>
RS> header styles, etc., but you are not given a choice. Should that
RS> <br>
RS> be changed? I don't think so...
RS> <br>
RS> <br>
RS> Open source software should be viewed as form of publication.
RS> <br>
RS> The same principle should apply.
RS> <br>
RS> <br>
RS> Edward
RS> <br>
RS> <br>
RS> At 01:29 PM 8/12/2004 -0500, Rod Spears wrote:
RS> <br>
RS> <blockquote type="cite">I agree that we should have a more "formal"
RS> meeting about our Kepler coding standards. And I agree that one style
RS> does not fit all.
RS> <br>
RS> <br>
RS> But I still think we need to have some way to distinguish the scope of
RS> a variable from its prefix. If folks don't like what I have proposed
RS> then pick something, but it can be rather confusing without a prefix
RS> (as I have found when reading some of the current code).
RS> <br>
RS> <br>
RS> As a suggestion consider this:
RS> <br>
RS> On Mozilla we had a general set of guidelines, which most us followed,
RS> but not everyone unfortunately. Of coarse, we could never agree on the
RS> curly brace issue, but we did a fairly good job on deciding on file
RS> names, interface file names, method argues, class data member names,
RS> and global names.
RS> <br>
RS> <br>
RS> The other overriding rule (especially because we had the notion of
RS> module ownership), was that you were to always make attempt to follow
RS> the coding standard of the files(s) you were working in.
RS> <br>
RS> <br>
RS> Meaning those who spent a lot of time in their modules had a little
RS> more flexibility in the style for those files, thus making it easier
RS> and more natural for those developers. Then, if by chance, you found
RS> yourself making changes to other people's code, you adapted to their
RS> style. The obvious idea was that you probably weren't going to be doing
RS> a lot of editting in other peoples code. Which, as it turns out, was
RS> pretty much true.
RS> <br>
RS> <br>
RS> I don't expect to be editting much if any Ptolemy code, etc. And it
RS> wouldn't make a lot of sense for someone to spend much time in the QB
RS> trying to fix a bug when I should probably be the fixing it.
RS> <br>
RS> <br>
RS> I think there is an economies of scale thing in here somewhere ;-)
RS> <br>
RS> <br>
RS> (Besides, outside of variable naming conventions, a lot of code can be
RS> reformatted with Eclipse or other tools)
RS> <br>
RS> <br>
RS> Rod
RS> <br>
RS> <br>
RS> <br>
RS> Edward A Lee wrote:
RS> <br>
RS> <blockquote type="cite">At 11:17 AM 8/12/2004 -0500, Rod Spears
RS> wrote:
RS> <br>
RS> <blockquote type="cite">Also, there seems to be some varying
RS> feelings and opinions about the coding style for Kepler. My approach
RS> which I am sure differs from Kepler is as follows:
RS> <br>
RS> <br>
RS> 1) All method arguments start with a lowercase "a"
RS> <br>
RS> 2) All class data members all start with "m" (unless they are final)
RS> <br>
RS> 3) All local variables have no prefix.
RS> <br>
RS> <br>
RS> It is my belief that you should always be able to look at a variable in
RS> the code and understand it's scope. I disagree with the approach where
RS> both the method arguments and the local variables have no prefix and
RS> are often distinguished by a "this.", which is rather verbose at times.
RS> <br>
RS> </blockquote>
RS> <br>
RS> While I think these are valid points,
RS> <br>
RS> I would like to make a case for following the coding style anyway...
RS> <br>
RS> <br>
RS> There is no coding style that will appeal to everyone (I guarantee it).
RS> <br>
RS> The benefits of having a uniform coding style, however, far outweigh
RS> <br>
RS> _any_ benefits you might derive from any particular coding style.
RS> <br>
RS> <br>
RS> So, I would suggest that the discussion needs to be:
RS> <br>
RS> <br>
RS> 1) What changes should be made to the uniform coding style?
RS> <br>
RS> 2) Who's going to do the work to convert the existing code base
RS> <br>
RS> to conform with any changes in the coding style?
RS> <br>
RS> <br>
RS> Number 2 suggests that changes had better have pretty compelling
RS> <br>
RS> reasons... I don't find the above reasons compelling enough...
RS> <br>
RS> (nor are they consistent: What if I name a local variable "model"?
RS> <br>
RS> Is it a class data member?).
RS> <br>
RS> <br>
RS> I think the concerns addressed by this proposal are adequately
RS> <br>
RS> addressed by keeping methods short and by choosing readable
RS> <br>
RS> names for variables that a compositions of full words and clearly
RS> <br>
RS> define the role of the variable.
RS> <br>
RS> <br>
RS> Edward
RS> <br>
RS> <br>
RS> <br>
RS> <br>
RS> ------------
RS> <br>
RS> Edward A. Lee, Professor
RS> <br>
RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
RS> <br>
RS> phone: 510-642-0455, fax: 510-642-2739
RS> <br>
RS> <a class="moz-txt-link-rfc2396E" href="mailto:eal at eecs.Berkeley.EDU"><mailto:eal at eecs.Berkeley.EDU></a><a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>,
RS> <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
RS> <br>
RS> </blockquote>
RS> <br>
RS> <br>
RS> --
RS> <br>
RS> Rod Spears
RS> <br>
RS> Biodiversity Research Center
RS> <br>
RS> University of Kansas
RS> <br>
RS> 1345 Jayhawk Boulevard
RS> <br>
RS> Lawrence, KS 66045, USA
RS> <br>
RS> Tel: 785 864-4082, Fax: 785 864-5335
RS> <br>
RS> </blockquote>
RS> <br>
RS> ------------
RS> <br>
RS> Edward A. Lee, Professor
RS> <br>
RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
RS> <br>
RS> phone: 510-642-0455, fax: 510-642-2739
RS> <br>
RS> <a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>, <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
RS> <br>
RS> <br>
RS> </blockquote>
RS> <br>
RS> <br>
RS> <div class="moz-signature">-- <br>
RS> <table>
RS> <tbody>
RS> <tr>
RS> <td
RS> style="border: 1px solid gray; font-size: 8pt; font-family: arial,sans-serif;">Rod
RS> Spears<br>
RS> Biodiversity Research Center<br>
RS> University of Kansas<br>
RS> 1345 Jayhawk Boulevard<br>
RS> Lawrence, KS 66045, USA<br>
RS> Tel: 785 864-4082, Fax: 785 864-5335<br>
RS> </td>
RS> </tr>
RS> </tbody>
RS> </table>
RS> </div>
RS> </body>
RS> </html>
More information about the Seek-dev
mailing list