Kris, can you look over and edit down your guidelines in the wiki? Thanks.
On Fri, Dec 18, 2009 at 3:18 AM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
Thank you for writing this up, Naftoli.
I edited the abbreviation section ...
Heiko
2009/12/18 Naftoli Gugenheim
Thank you for writing this up, Naftoli.
I edited the abbreviation section ...
Heiko
2009/12/18 Naftoli Gugenheim naftoli...@gmail.com
(Not sure why on Chrome the wiki article page is all centered. Reported it
to Chrome.)
Can everyone look over the article? Especially everyone quoted in it
(Not sure why on Chrome the wiki article page is all centered. Reported it
to Chrome.)
Can everyone look over the article? Especially everyone quoted in it --
Kris, Jim, DPP, Heiko, and anyone who I may have missed -- can you make sure
everything represents your opinion correctly?
Then if there
2009/12/15 David Pollak feeder.of.the.be...@gmail.com
5) Avoid using abbreviations
I disagree. When coding with a non-IDE, abbreviations make life much
easier.
When using abbreviations, could the abbreviation be documented even it if it
the most mind numbingly obvious abbreviation as
Is that sufficiently expressed in the wiki article draft (look for Jim)? If
not, what would you add?
-
Jonathan Fergusonj...@spiralarm.com wrote:
2009/12/15 David Pollak feeder.of.the.be...@gmail.com
5) Avoid using abbreviations
I disagree. When
I compiled much of this thread into
http://wiki.github.com/dpp/liftweb/about-naming-conventions in raw form. As
we continue to discuss the naming goals and guidelines and vote or decide on
controversial goals, that wiki page should become more consolidated and less
of a copy-paste of a discussion.
Folks,
Lift allows developers to create web sites that are:
1. Reliable (which includes secure)
2. Maintainable/concise
3. Highly interactive
4. Easy to build
5. High Performance
6. Easy to on-board (initial understanding of the APIs)
Lift's APIs should reflect these
This is such a preference. Most people use IDEs, I personally dont, but I would
still choose clarity and marginal verbosity over less typing. A classic is some
places in lift we call it calc and other palces its calculator
Cheers, Tim
On 14 Dec 2009, at 19:34, David Pollak wrote:
I
I snipped some stuff.
On Mon, Dec 14, 2009 at 12:34 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Sun, Dec 13, 2009 at 10:39 PM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
2009/12/13 Kris Nuttycombe kris.nuttyco...@gmail.com
5) Avoid using abbreviations
I
5) Avoid using abbreviations
I disagree. When coding with a non-IDE, abbreviations make life much
easier.
I agree with David, abbreviations are better. When I'm trying to get
something out of my head and into code, I don't want things getting in my
way. 2 things in this scenario get
I'm not sure you can generalize whether abbreviations are good or bad. It
depends how obvious their meaning is. No one in favor of abreviations wants to
replace say JSONResponseType (if such a name exists) with JRT! Nor does anyone
want to replace JSON with JavaScriptObjectNotation. Everyone
Do you have benchmarks comparing the differences in time?
Just kidding. :)
But I would like to point out, I understand your position, but I think many
people would use the exact same argument against abbreviations, if they make it
take longer to figure out or remember what their called!
Some
Do you have benchmarks comparing the differences in time?
Just kidding. :)
But I would like to point out, I understand your position, but I think many
people would use the exact same argument against abbreviations, if they make it
take longer to figure out or remember what their called!
Some
On Mon, Dec 14, 2009 at 12:31 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Folks,
Lift allows developers to create web sites that are:
Reliable (which includes secure)
Maintainable/concise
Highly interactive
Easy to build
High Performance
Easy to on-board (initial understanding
To this point, the only goals that have been recommended for this
effort are those that I've noted below:
1) Remove ambiguity wherever possible! There are a number of places
where very similar names are used to refer to utterly different
things.
2) As an aide removing ambiguity, consider
I agree very strongly that this is the principle goal. A good name expresses
what it refers to succintly, and if that is not enough to inform one exactly
what it is, once one learns what it is then he sees how obvious it is from
the name and it is an efficient, effective reminder. (If something
2009/12/13 Kris Nuttycombe kris.nuttyco...@gmail.com
To this point, the only goals that have been recommended for this
effort are those that I've noted below:
1) Remove ambiguity wherever possible! There are a number of places
where very similar names are used to refer to utterly different
And here is another one:
6) Use names related to the nature of the thing being named: We should be
able to know what a type is or a method does from reading its name.
Heiko
My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
18 matches
Mail list logo
