- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Emacs scala-mode indentation of if statement
Thu, 2009-03-26, 14:40
>>>>> "Ricky" == Ricky Clarkson writes:
Ricky> Adjust to the Scala way, or you will cause unwarranted bugs and
Ricky> confusing compile errors.
Ricky> Code with next-line braces, as I wrote for years, focuses too
Ricky> much on structure and not enough on intent. A spell of Common
Ricky> Lisp cured me.
I spent much of the 90's writing Common Lisp and Scheme, so today I find
I have to resist the temptation to write my Scala like:
if(args.isEmpty) {
print("input file name: ")
readLine }
In fact, sometimes I consider just going ahead and giving in to the
temptation and making this my standard style. If I were only the coder
on my project I'd probably at least try it for a while, but I imagine
others would find it too extreme.
In general, I really find it just enormously, enormously helpful for my
overall productivity as a programmer if I work on code that takes up less
vertical space. It's true that vertical compression makes code slightly
harder to read. But increasingly, I think it's actually much more
important to have more code on-screen at once. Consider: the
readability of code that isn't on my screen at the moment is literally
zero -- I can't read it if I can't see it!
Now that we're all using editors that do syntax-highlighting in color,
I find the colors (and the indentation, of course) supply the
needed visual cues to make vertically compressed code readable.
Thu, 2009-03-26, 17:47
#2
Re: Emacs scala-mode indentation of if statement
On Thursday March 26 2009, Ricky Clarkson wrote:
> > if(args.isEmpty) {
> > print("input file name: ")
> > readLine }
>
> One problem I find with that, which I never noticed in CL, is that if
> I start removing the if, then lose concentration (e.g., get handed a
> baby to hold), it then becomes unclear what the } should have
> matched, especially if there's a lot of code around. When the } has
> its own line, it's a lot more obvious.
When I do Lisp, which is infrequently, I usually put many of an
expression's closing parens on their own line while I'm working on that
expression. Once I'm satisfied the code is correct, I'll join the
orphaned close parens onto the last line of code. If I need to work on
a complex expression, I'll often peel of trailing parens for the
duration of the surgery.
Randall Schulz
> if(args.isEmpty) {
> print("input file name: ")
> readLine }
One problem I find with that, which I never noticed in CL, is that if
I start removing the if, then lose concentration (e.g., get handed a
baby to hold), it then becomes unclear what the } should have matched,
especially if there's a lot of code around. When the } has its own
line, it's a lot more obvious.
2009/3/26 Seth Tisue :
>>>>>> "Ricky" == Ricky Clarkson writes:
>
> Ricky> Adjust to the Scala way, or you will cause unwarranted bugs and
> Ricky> confusing compile errors.
>
> Ricky> Code with next-line braces, as I wrote for years, focuses too
> Ricky> much on structure and not enough on intent. A spell of Common
> Ricky> Lisp cured me.
>
> I spent much of the 90's writing Common Lisp and Scheme, so today I find
> I have to resist the temptation to write my Scala like:
>
> if(args.isEmpty) {
> print("input file name: ")
> readLine }
>
> In fact, sometimes I consider just going ahead and giving in to the
> temptation and making this my standard style. If I were only the coder
> on my project I'd probably at least try it for a while, but I imagine
> others would find it too extreme.
>
> In general, I really find it just enormously, enormously helpful for my
> overall productivity as a programmer if I work on code that takes up less
> vertical space. It's true that vertical compression makes code slightly
> harder to read. But increasingly, I think it's actually much more
> important to have more code on-screen at once. Consider: the
> readability of code that isn't on my screen at the moment is literally
> zero -- I can't read it if I can't see it!
>
> Now that we're all using editors that do syntax-highlighting in color,
> I find the colors (and the indentation, of course) supply the
> needed visual cues to make vertically compressed code readable.
>
> --
> Seth Tisue / http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>