A note: Both variants below do not look nice because of the code
starting at the first column.
Some of the method body code lines start in the first column:
Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].]
vs.
Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint
[
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].
]
What about adding 4 leading spaces, easy to remove when parsing.
Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].]
vs.
Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint
[
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].
]
--Hannes
On 9/11/17, Stephane Ducasse <[email protected]> wrote:
> I read all the morph class and I like the ending ] at the beginning of
> the line (even if I know the rectangle concern for ifTrue beck
> formatting)
> Why because it identifies really well the end of a method.
>
> It is especially good for method finishing with conditionals.
>
> ]
>
> Esteban
>
> could you generate the same class with
>
> MethodDeclaration
> [
> ....
> ]
>
> I would like to browse it to see how the eye catch fast.
>
> because
>
> MethodDeclaration
> [
> ....
> ]
> is not that nice
>
> so may be
>
> MethodDeclaration [
> ....
> ]
>
> is a good compromise (because end of method is more important to spot that
> beginning.
>
> Stef
>
>