Hi,
I do not understand the arguments that go in the direction of: because
a block is an object, it should have no spaces inside and it should
not have the code starting on a new line. This is a bit like saying
that a method should not be indented and the code should start on the
same
2010/3/4 Tudor Girba tudor.gi...@gmail.com:
Hi,
I do not understand the arguments that go in the direction of: because
a block is an object, it should have no spaces inside and it should
not have the code starting on a new line. This is a bit like saying
that a method should not be indented
Strange to see how subjective it is...
My brain is well trained to rectangle blocks and I arrive to the
opposite conclusions on each point.
I agree 100% with all that Doru wrote. These patterns have been
successfully used for almost a decade in open-source projects like
Seaside, Moose,
On Thu, Mar 4, 2010 at 10:08 AM, Lukas Renggli reng...@gmail.com wrote:
Strange to see how subjective it is...
My brain is well trained to rectangle blocks and I arrive to the
opposite conclusions on each point.
I agree 100% with all that Doru wrote. These patterns have been
successfully
Another visual problem with [ and ] is that they are but one
character, and if you place them together with something else, like
[self, they lose their visual identity (btw, we read words in chunks
not by characters) and get harder to spot. It's true that some fonts
and extra coloring could
It is obvious that a consensus will not be reached on the one and only true
format.
If my browser displays code formatted the way I want to see it and the
difference tools are format neutral (i.e., the source and target code is
formatted using the same rules) there is no need to agree on a
yes for tool support even if I would like to have the code of the core to be
nicely and consistently formatted.
Since I learned smalltalk with VW I like
someVar = someValue
| ifTrue: [self doOneThing]
| ifFalse:
| [self
|
+1
On Mar 4, 2010, at 19:10 , Dale Henrichs wrote:
It is obvious that a consensus will not be reached on the one and only true
format.
If my browser displays code formatted the way I want to see it and the
difference tools are format neutral (i.e., the source and target code is
-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian
Lienhard
Sent: Thursday, March 04, 2010 2:49 PM
To: Pharo Development
Subject: Re: [Pharo-project] about code formatting in pharo
+1
On Mar 4, 2010, at 19:10 , Dale Henrichs wrote
So how does that sound? Just dispatching portions of the various
printing methods in subclasses of ParseNode to a Printer that allows
individual preferences to be specified?
This thing is called RBConfigurableFormatter and it has been present
for the last decade.
Lukas
--
Lukas Renggli
Cool, present is a start. But how do I use it?
In Pharo 10508, I executed:
RBConfigurableFormatter stringFollowingReturn: ''--- String empty
and then tried the format option in a method that has ^ something,
but it did not remove the extra space. In fact, I'm not sure it even
tried to
and then tried the format option in a method that has ^ something,
but it did not remove the extra space. In fact, I'm not sure it even
tried to format anything; I didn't have time to debug it. In any
case, if Pharo is using RB for formatting then separate solutions for
Squeak and Pharo may
Gary wrote:
The answer is that the code is formatted when viewing, from, potentially,
unformatted code. Should please everyone.
+1
Looks like in Squeak the rules from Ward Cunningham are now used for pretty
print:
http://c2.com/ppr/formatting.html#2
See Compiler-cmm.131.mcz in Squeak.
--
On Mar 3, 2010, at 9:26 AM, Torsten Bergmann wrote:
Gary wrote:
The answer is that the code is formatted when viewing, from, potentially,
unformatted code. Should please everyone.
+1
Looks like in Squeak the rules from Ward Cunningham are now used for pretty
print:
On Mar 3, 2010, at 9:26 AM, Torsten Bergmann wrote:
Gary wrote:
The answer is that the code is formatted when viewing, from, potentially,
unformatted code. Should please everyone.
+1
Looks like in Squeak the rules from Ward Cunningham are now used for pretty
print:
what do you mean
I don't like Beck's rule 3. Rectangular Block:
b ifTrue:
[self clearCaches.
self recomputeAngle]
I prefer (and this is how most other people format blocks in my experience):
b ifTrue: [
self clearCaches.
self recomputeAngle ]
Adrian
On Mar 3, 2010, at 10:03 ,
Really? That's the first time I've ever seen a lonely left bracket like
that, in all my 15 years of Smalltalk experience!
So for me personally, Beck's rule 3 is the one that looks better.
--
Cheers,
Peter
On Wed, Mar 3, 2010 at 10:19 AM, Adrian Lienhard a...@netstyle.ch wrote:
I don't like
what do you mean by now used?
Did they change that recently?
According to http://planetmisc.squeak.org/
a new package Compiler-cmm.131.mcz is now in Squeak inbox
and may find its way into trunk ...
I don't like Beck's rule 3. Rectangular Block
vs.
So for me personally, Beck's rule 3 is the one
Well, Kent makes a well-reasoned argument for Rectangular Block,
readability and productivity. I don't like it is just a statement
of someone's personal taste, a non-starter in terms of a useful
discussion about formatting.
My goal is to make the system more productive and, by my experience,
Isn't readability a matter of taste, or were experiments done?
IIRC, the arguments for productivity had to do with everyone just
accepting one standard - not that one standard was better than
another, just that there be *one* team standard (in the interest of
productivity).
I prefer the
On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu ya...@rogers.com wrote:
Isn't readability a matter of taste...?
Not according to the pattern description; did you read it? It says,
the tendency of the eye to distinguish and interpolate vertical and
horizontal lines. The square brackets used to
On Mar 3, 2010, at 16:53 , Yanni Chiu wrote:
Isn't readability a matter of taste, or were experiments done?
Indeed. As long as we don't carry out usability studies, we don't know what is
better and we have to resort to personal taste. When I said I don't like x I
also meant I find it is less
El mié, 03-03-2010 a las 10:19 +0100, Adrian Lienhard escribió:
I don't like Beck's rule 3. Rectangular Block:
b ifTrue:
[self clearCaches.
self recomputeAngle]
I prefer (and this is how most other people format blocks in my experience):
b ifTrue: [
self clearCaches.
On Mar 3, 2010, at 4:53 PM, Yanni Chiu wrote:
Isn't readability a matter of taste, or were experiments done?
IIRC, the arguments for productivity had to do with everyone just
accepting one standard - not that one standard was better than
another, just that there be *one* team standard
+ 1
And I know that you read kent patterns.
We got all brainwashed with them I;m still hoping that his book will be out
of print :)
For now rebuying one for the team here since some guys messed up my nice and
clean version.
Stef
On Mar 3, 2010, at 16:53 , Yanni Chiu wrote:
Isn't
Chris Muller wrote:
On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu ya...@rogers.com wrote:
Isn't readability a matter of taste...?
Not according to the pattern description; did you read it? It says,
the tendency of the eye to distinguish and interpolate vertical and
horizontal lines. The
On Wed, Mar 3, 2010 at 1:50 PM, Yanni Chiu ya...@rogers.com wrote:
Chris Muller wrote:
On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu ya...@rogers.com wrote:
Isn't readability a matter of taste...?
Not according to the pattern description; did you read it? It says,
the tendency of the eye
ifTrue: [
line1 yo.
line2 eh ]
Horrible, horrible, horrible ;) Poor block. The block is an object...
Exactly what I was thinking; and how some of the new editor features
since 3.9, that seem to reify statements. For example, clicking
inside parens or square-brackets
Cool. If we can tweak the formatter to fit our needs, I think this is an
interesting idea because we would then have really consistent formatting. How
does one use this formatter? Something else to consider is that we would need
to run the formatter in PharoCore, but it does not contain RB. We
01, 2010 6:53 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
Cool. If we can tweak the formatter to fit our needs, I think this is an
interesting idea because we would then have really consistent formatting. How
does one use this formatter
Cool. If we can tweak the formatter to fit our needs, I think this is an
interesting idea because we would then have really consistent formatting.
It has dozens of settings that you can configure. It is already
integrated with the settings framework in Pharo 1.1.
How does one use this
How does one use this formatter?
aClass compile: (aClass parseTreeFor: aSelector) formattedCode
OB-Refactory also provides a UI to format the whole system or
individual classes or packages.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
___
Another approach would be to have a Seaside app that accepts uploads of .mcz
files, loads, formats, and re-saves them into an in-box. I still recommend
getting the RB's house in order with respect to comments, but it would work
as well as RB users have come to expect. It would also make
, March 01, 2010 7:28 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
Another approach would be to have a Seaside app that accepts uploads of .mcz
files, loads, formats, and re-saves them into an in-box. I still recommend
getting the RB's
would be nice :)
scripting the core from external services
Stef
On Mar 1, 2010, at 12:52 PM, Adrian Lienhard wrote:
Cool. If we can tweak the formatter to fit our needs, I think this is an
interesting idea because we would then have really consistent formatting. How
does one use this
On Mar 1, 2010, at 1:23 PM, Lukas Renggli wrote:
Cool. If we can tweak the formatter to fit our needs, I think this is an
interesting idea because we would then have really consistent formatting.
It has dozens of settings that you can configure. It is already
integrated with the settings
back.
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas
Renggli
Sent: Monday, March 01, 2010 7:28 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code
I'm not complaining; it's simply a fact, and I'm not the only one observing
it. Links were given here some time back.
Sorry, but this is only a fact if you provide unit tests (or at least
a couple of examples) that fail in the latest code base. Otherwise
simply nobody cares.
Lukas
--
Lukas
] On Behalf Of Lukas Renggli
[reng...@gmail.com]
Sent: Monday, March 01, 2010 7:47 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
I'm not complaining; it's simply a fact, and I'm not the only one observing
it. Links were given here some
Stef,
I really like formatters, but as the discussion has already shown, there isn't
one format that fits everyone's definition of beauty/readability.
Personally I am willing to use any formatter that saves me from having to hand
edit code for format, but I think I am in the minority.
-project@lists.gforge.inria.fr
Cc: Pharo-project Development Pharo-project@lists.gforge.inria.fr
Sent: Monday, March 01, 2010 6:06 PM
Subject: Re: [Pharo-project] about code formatting in pharo
Stef,
I really like formatters, but as the discussion has already shown, there
isn't one format
-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Dale Henrichs
Sent: Monday, March 01, 2010 1:07 PM
To: Pharo-project@lists.gforge.inria.fr
Cc: Pharo-project Development
Subject: Re: [Pharo-project] about code formatting in pharo
Stef,
I
, 2010 6:23 PM
Subject: Re: [Pharo-project] about code formatting in pharo
Stef,
To that reasoned response I will add that I do not at all care what others
choose to use in their code; I simply don't want a formatter applied to my
code that lives in my image. Whatever works for you
01, 2010 1:21 PM
To: Pharo-project@lists.gforge.inria.fr; dale.henri...@gemstone.com
Subject: Re: [Pharo-project] about code formatting in pharo
The answer is that the code is formatted when viewing, from, potentially,
unformatted code. Should please everyone. Of course, nothing to stop code being
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Gary Chambers
Sent: Monday, March 01, 2010 1:26 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
Perhaps
Subject: Re: [Pharo-project] about code formatting in pharo
I'm not complaining; it's simply a fact, and I'm not the only one observing
it. Links were given here some time back.
Sorry, but this is only a fact if you provide unit tests (or at least
a couple of examples) that fail
Subject: Re: [Pharo-project] about code formatting in pharo
Gary,
That's pretty much what I just proposed based on your suggestion and a
null formatter. However it is implemented, the idea is to render the
code using a formatter so the code itself is not altered. That will
hopefully give
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli
Sent: Monday, March 01, 2010 1:32 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
Excellent
...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Gary Chambers
Sent: Monday, March 01, 2010 1:45 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
Just the issue of resaved code then... I suggest a compact
-project Development
Subject: Re: [Pharo-project] about code formatting in pharo
Stef,
I really like formatters, but as the discussion has already shown, there
isn't one format that fits everyone's definition of beauty/readability.
Personally I am willing to use any formatter that saves
Renggli
[reng...@gmail.com]
Sent: Monday, March 01, 2010 7:47 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
I'm not complaining; it's simply a fact, and I'm not the only one observing
it. Links were given here some time back.
Sorry
Hi guys
I would like to build a set of canonical code formatting convention for Pharo.
I need your help. Now take time before replying :)
I would like to structure the discussion and proceed step by step. So at max I
would like to discuss one or two formatting approach per mail.
Once we agree I
I would use a formatter, like this you can make it really consistent.
The RBConfigurableFormatter is pretty good in that, the only thing I
don't like is the placing of the square brackets. I should look into
fixing that, otherwise it formats exactly the way I would format
myself (and in the way
Lukas do you have some code samples.
Something that I particularly hate is the following
self bla ifTrue: [
...
] ifFalse: [
...
]
That is see in the code.
I want
self bla
ifTrue: [ ...
On 28 February 2010 11:58, Stéphane Ducasse stephane.duca...@inria.fr wrote:
Lukas do you have some code samples.
Something that I particularly hate is the following
self bla ifTrue: [
...
] ifFalse: [
...
]
That is see in the code.
I
Looks good to me
If one day we get a cooler one we could get
self class isVariable anotherObject class isVariable
ifTrue:
[ 1 to: (self basicSize min: anotherObject basicSize)
do: [ :ind |
self basicAt: ind put: (anotherObject basicAt: ind) ] ]
But, if there is only single block, i usually typing:
self bla ifTrue: [
code.
code.
]
Yes I see
I would prefer
self bla ifTrue: [
code.
code. ]
for me I try
self bla ifTrue: [ code ].
or
self bla
ifTrue: [ code.
code.]
but I'm not happy because
On 28 February 2010 12:44, Stéphane Ducasse stephane.duca...@inria.fr wrote:
But, if there is only single block, i usually typing:
self bla ifTrue: [
code.
code.
]
Yes I see
I would prefer
self bla ifTrue: [
code.
code. ]
for me I try
self bla ifTrue: [ code ].
yes,
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli
Sent: Sunday, February 28, 2010 4:52 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
I would use a formatter, like this you can make it really consistent
On Feb 28, 2010, at 1:58 AM, Stéphane Ducasse wrote:
Lukas do you have some code samples.
Something that I particularly hate is the following
self bla ifTrue: [
...
] ifFalse: [
...
]
I'd like to understand what it is about the above you
On Sun, 28 Feb 2010, James Foster wrote:
On Feb 28, 2010, at 1:58 AM, Stéphane Ducasse wrote:
Lukas do you have some code samples.
Something that I particularly hate is the following
self bla ifTrue: [
...
] ifFalse: [
...
]
I'd
-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian
Lienhard
Sent: Sunday, February 28, 2010 8:11 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
I've attached the coding conventions that we use at Cmsbox and netstyle.ch.
They closely
...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian
Lienhard
Sent: Sunday, February 28, 2010 8:11 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
I've attached the coding conventions that we
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian
Lienhard
Sent: Sunday, February 28, 2010 2:52 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
Hi
thanks adrian
On Feb 28, 2010, at 2:11 PM, Adrian Lienhard wrote:
I've attached the coding conventions that we use at Cmsbox and netstyle.ch.
They closely follow the suggestions of Kent Beck's Smalltalk Best Practice
Patterns.
According to these rules I would format the following
+ 10
I'd like to understand what it is about the above you hate.
It's like C code, not like a message send. Do you write code like this?
aCollection do: [ :each |
...
] separatedBy: [
...
]
That is see in the code.
I want
self bla
ifTrue: [ ...
...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian
Lienhard
Sent: Sunday, February 28, 2010 8:11 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] about code formatting in pharo
I've attached the coding conventions that we
Hi James
Lukas do you have some code samples.
Something that I particularly hate is the following
self bla ifTrue: [
...
] ifFalse: [
...
]
I'd like to understand what it is about the above you hate.
See levente
In addition I have to apy
I've commented a version of RBConfigurableFormatter that can format
#copyFrom: to the following code. This comes pretty close to the
document of Adrian:
ObjectcopyFrom: anotherObject
Copy to myself all instance variables I have in common with
anotherObject. This is dangerous because it
Thanks lukas
I've commented
commited :) I guess I saw in on the rss feed :)
a version of RBConfigurableFormatter that can format
#copyFrom: to the following code. This comes pretty close to the
document of Adrian:
ObjectcopyFrom: anotherObject
Copy to myself all instance
I've commented
commited :) I guess I saw in on the rss feed :)
Yeah.
can we get rid of the
:ind |
Select 'ind', in the context menu select 'refactor source', 'rename
temporary'. Then give the new name 'index', press 'ok'. Done.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote:
---
1
to: (mine size min: his size)
do: [ :index |
(mine at: index) = (his at: index) ifTrue: [
self
instVarAt: index
put:
The configurable formatter can be told from how many keyword messages
on it should put them on multiple lines. Also you can give exceptions
of messages that you always/never want to put on multiple lines.
Lukas
On 28 February 2010 22:29, Adrian Lienhard a...@netstyle.ch wrote:
On Feb 28, 2010,
On Feb 28, 2010, at 10:28 PM, Lukas Renggli wrote:
I've commented
commited :) I guess I saw in on the rss feed :)
Yeah.
can we get rid of the
:ind |
Select 'ind', in the context menu select 'refactor source', 'rename
temporary'. Then give the new name 'index', press 'ok'. Done.
On 28 February 2010 22:38, Stéphane Ducasse stephane.duca...@inria.fr wrote:
On Feb 28, 2010, at 10:28 PM, Lukas Renggli wrote:
I've commented
commited :) I guess I saw in on the rss feed :)
Yeah.
can we get rid of the
:ind |
Select 'ind', in the context menu select 'refactor
lol
I was really skeptical :)
:ind | at the beginning of the line.
Ahh, that was the mail program that broke it there.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
: [Pharo-project] about code formatting in pharo
you know go (the language) includes in the language the formatting so there is
no discussion.
Now I really like to see smalltalk code and not C code because.
It slows me down a lot when I read and I read a lot of code. :)
Stef
On Feb 28, 2010
77 matches
Mail list logo
