Code style: Length of lines
Piotr Kołaczkowski
I noticed that when programming in Scala, I tend to write much longer
lines than in imperative languages (eg. in Java). I often feel 80
characters is too little. Do you also notice this, or is it just me?
What is your coding style? Do you exceed the traditional 80 character
limit? Or do you use a wider limit (displays are quite wide these
times)? How do you format code, not to exceed it? What I'm most curious
about is how to layout method and class declarations - these often tend
to be long and look unreadable when split into several lines.
Regards,
Piotr
Tony Morris
implications?" Apply critical analysis to this question. Be careful of
falling in to the mindless adherence to nonsense trap.
--
Tony Morris
http://tmorris.net/
Hasan Ozgan
--
Hasan Ozgan (a.k.a meddah)
Web Solution Architect
Francois
I tend to use 120 char lines, with two spaces indentations and open { in
the same line - the last two are for easy copy/paste to REPL.
For formatting... there must be tone of details. One example:
maylist { case(x,y) =>
x match {
case CASE_1 if( garde ) => //do something with x/y
case CASE_2 => //do something with x/y
case _ => //etc
}
}
That does not always hold, when gards are really long. In that cases,
the style is often ad-hoc.
For case classes with long args list:
case class(
param1 : TYPE,
param2 : TYPE[T1,T2],
//etc
)
I start to from some Scala and Javascript & JSON (and Haskell ?) code
that syntax, which seems appealing:
case class(
param1 : TYPE,
, param2 : TYPE[T1,T2]
, param3 : T
//etc
)
And I thing there is already too much on that mail to start a long debate...
--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com
Randall R Schulz
> https://github.com/davetron5000/scala-style
>
> *PDF Files*
> http://davetron5000.github.com/scala-style/ScalaStyleGuide.pdf
> http://davetron5000.github.com/scala-style/
> http://www.codecommit.com/scala-style-guide.pdf
I prefer Tony's approach.
Randall Schulz
Alec Zorab
guide itself, the rules are there to be broken, but it makes reading
other people's code somewhat easier if you're aware of the conventions
within the general corpus (not to mention making your own code easier
to read for others).
Randall R Schulz
> ... it makes reading
> other people's code somewhat easier if you're aware
That makes no sense whatsoever.
Code is as easy to read as it is.
Randall Schulz
Alec Zorab
class names, you disapprove of the java convention of prefix private
members with '_' etc?
Dennis Haupt
the variable names, methods, complexity and so on are much, much more important
-------- Original-Nachricht --------
> Datum: Fri, 11 Mar 2011 15:19:36 +0000
> Von: Alec Zorab <alec...@googlemail.com>
> An: Randall R Schulz <rsc...@sonic.net>
> CC: scala...@googlegroups.com
> Betreff: Re: [scala-user] Code style: Length of lines
Alec Zorab
to infer the origin of a variable by the presence of an underscore, or
whether a symbol is a method or a field by the case of the first
letter (for example). I actually tend to rely on this less when
working with intellij, but I still think that clues like this can make
a serious difference to how quickly I can pick up someone else's code.
Philippe Lhoste
> i never was faster or slower reading someones code just because of his low level coding conventions
Then I suppose you never (or rarely) read code from beginners... I do that a lot in the
Processing forum, and I often suffer from random indentation (or none at all), random
capitalization (classes starting with lower case, variable names starting with upper case
-- why not, but it slightly disturbs by breaking habits, and there is often lack of
consistency inside the same code!) and so on...
On 11/03/2011 16:30, Alec Zorab wrote:
> So you don't give your classes meaningful names, you don't capitalise
> class names, you disapprove of the java convention of prefix private
> members with '_' etc?
The latter isn't so frequently used, actually, and isn't, AFAIK, in the Java style
recommendations. (But I don't disapprove it ^_^)
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Dennis Haupt
there is no need to use parts of the name for something a text renderer can do.
-------- Original-Nachricht --------
> Datum: Fri, 11 Mar 2011 15:45:16 +0000
> Von: Alec Zorab <alec...@googlemail.com>
> An: Dennis Haupt <h-s...@gmx.de>
> CC: rsc...@sonic.net, scala...@googlegroups.com
Dennis Haupt
-------- Original-Nachricht --------
> Datum: Fri, 11 Mar 2011 16:55:06 +0100
> Von: Philippe Lhoste <Phi...@GMX.net>
> An: scala...@googlegroups.com
> Betreff: [scala-user] Re: Code style: Length of lines
Philippe Lhoste
> i never have trouble pressing the "format code" hotkey right after opening a file in my ide either :)
I don't have such button in my browser...
On 11/03/2011 17:05, Dennis Haupt wrote:
> me too, but my color style aka intellij's color style engine does all of this for me.
local vals, vars, parameters, class names, fields, defs, constructor calls - everything
has a different colored underscore, is bold, italic or the text is written in another color.
>
> there is no need to use parts of the name for something a text renderer can do.
Except sometime you read code in the Web interface of a repository, in a forum or a
mailing list, in a simple editor with limited syntax highlighting (you don't always want
to load a full project in your IDE to browse some code), and so on.
Vlad Patryshev
--
Thanks,
-Vlad
Vlad Patryshev
--
Thanks,
-Vlad
Alec Zorab
for have all done this, but I'm willing to believe it's not an
official Java thing.
Philippe Lhoste
> In Google several years ago people voted for 100 char per line in Java. No negative impact
> observed.
That's my personal choice, arbitrary, just because it is a round number...
80 chars was chosen in the past because it was the standard width of a text screen...
100 fits nicely in my text editor window with my font of choice when the application is
roughly at half the width of the screen, which allows to see the Windows Explorer file
list and allows fast drag'n'drop of files from the Explorer to the editor... ^_^'
Philippe Lhoste
> Fair enough. By strange coincidence, the last 3 java shops I've worked
> for have all done this, but I'm willing to believe it's not an
> official Java thing.
At my work place, they chose the Microsoft convention (I think the main programmer, at the
start of the project, used to code in Visual Studio before...) of the m_ prefix on the
class members (using s_ for static, non final variables). Funnily, it was also my personal
choice in my own coding rules... '^_^
Somehow, it isn't so far from the convention you describe (which isn't so uncommon, to be
honest).
But general consensus on Java code is just to leave members undecorated, using the ugly
(IMHO) this.someVar = someVar form in constructors. And making inconvenient (in plain
text) to distinguish members from local variables. [Duck to avoid flames...]
Matthew Pocock
Kevin Wright
On 11 Mar 2011 18:00, "Philippe Lhoste" <Phi...@gmx.net> wrote:
>
> On 11/03/2011 18:40, Alec Zorab wrote:
>>
>> Fair enough. By strange coincidence, the last 3 java shops I've worked
>> for have all done this, but I'm willing to believe it's not an
>> official Java thing.
>
>
> At my work place, they chose the Microsoft convention (I think the main programmer, at the start of the project, used to code in Visual Studio before...) of the m_ prefix on the class members (using s_ for static, non final variables). Funnily, it was also my personal choice in my own coding rules... '^_^
>
> Somehow, it isn't so far from the convention you describe (which isn't so uncommon, to be honest).
> But general consensus on Java code is just to leave members undecorated, using the ugly (IMHO) this.someVar = someVar form in constructors. And making inconvenient (in plain text) to distinguish members from local variables. [Duck to avoid flames...]
>
Let me divert some of those flames for you, I already have a plentiful supply of asbestos to hand :)
Scala has already managed to neatly sidestep these issues by unifying class definition and a primary constructor. The uniform access principle also helps out a lot here, as does immutability.
class Bippy(val prop1: Int)
prop1 is now a final field, constructor argument, and a prop1() method callable from java...
Matt Russell
wrote:
> over ssh on an 80 column terminal with no IDE to patch some mission-critical
> source. On that day, you will owe beer to the devs who have made sure their
> code is correctly indented and fits within 80 columns and follows coding
> conventions.
rather optimise code style for the environment in which people spend
99% of their time, rather than the 1%.
-- Matt
Mike
> I find it enormously useful to be able to infer [...] whether a symbol
Sounds like a violation of the Uniform Access Principle.
Brian Maso
In Google several years ago people voted for 100 char per line in Java. No negative impact observed.
100 is soooo decimal. 128 would be much better!
Brian Maso
2011/3/11 Piotr Kołaczkowski <pkol...@elka.pw.edu.pl>
Hello,
I noticed that when programming in Scala, I tend to write much longer lines than in imperative languages (eg. in Java). I often feel 80 characters is too little. Do you also notice this, or is it just me?
What is your coding style? Do you exceed the traditional 80 character limit? Or do you use a wider limit (displays are quite wide these times)? How do you format code, not to exceed it? What I'm most curious about is how to layout method and class declarations - these often tend to be long and look unreadable when split into several lines.
Regards,
Piotr
--
Thanks,
-Vlad
--
Best regards,
Brian Maso
(949) 395-8551
br...@blumenfeld-maso.com
Tony Morris
as a readability aid. Be careful of that which masquerades as a
readability aid.
Peter C. Chapin
> 2011/3/11 Vlad Patryshev <vpatr...@gmail.com>
>
> In Google several years ago people voted for 100 char per line in Java. No negative impact observed.
>
>
> 100 is soooo decimal. 128 would be much better!
A few years ago I switched my personal standard from 80 character lines to
96 character lines. Why 96? Well, it's 64 + 32 (and so it's a "kind of"
round number) and yet is still short enough so that it can be printed on
letter sized paper without wrapping using a normal font (with margins).
Who cares about printing code? Good question. There are still a few
occasions when I feel the need to do it. I tried using 128 character lines
but that just don't fit on the hard copy all that well.
That said, I do have some projects where I use 128 character lines as a
project standard for reasons related to that project (those projects are not
in Scala, however).
Peter
Randall R Schulz
> There's always that time when you have to dial in half way across the
> world over ssh on an 80 column terminal
There's no such thing any more. Yes, I have a Televideo 950, but it has
no utility whatsoever as an access device for contemporary computing
systems.
> with no IDE to patch some
> mission-critical source. On that day, you will owe beer to the devs
> who have made sure their code is correctly indented and fits within
> 80 columns and follows coding conventions.
Such a quaint scenario. Preposterous, but quaint.
And only Python and Haskell even have a notion of "correctly indented."
Randall Schulz
Randall R Schulz
> ...
>
> That's my personal choice, arbitrary, just because it is a round
> number... 80 chars was chosen in the past because it was the standard
> width of a text screen...
No, it was the number of columns available for character codes on a
Hollerith card.
What a wonderful tradition to honor: That of antique electromechanical
computing devices.
> ...
Randall Schulz
Stefan Wagner
Hash: SHA1
Hi Matthew,
Hi List,
> There's always that time when you have to dial in half way across the world
> over ssh on an 80 column terminal with no IDE to patch some mission-critical
> source. On that day, you will owe beer to the devs who have made sure their
> code is correctly indented and fits within 80 columns and follows coding
> conventions.
tar -cf - ./tmp | ssh clienthost " ( cd /home/stefan/fixit ; tar -xf - ) "
if you don't have an scp possibility.
Tsch���--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAk17KbUACgkQQeATqGpDnRrlZQCfQXMiEyChlyipPrr6U/Rc5geV
mmgAn0sTxdH7C1mtvy2xoiAhH0MIL8L1
=e5x0
-----END PGP SIGNATURE-----
Jim Balter
> On Friday March 11 2011, Philippe Lhoste wrote:
>> ...
>>
>> That's my personal choice, arbitrary, just because it is a round
>> number... 80 chars was chosen in the past because it was the standard
>> width of a text screen...
>
> No, it was the number of columns available for character codes on a
> Hollerith card.
Which is why those old 80x24 screens were 80 columns wide. It's funny
that people not old enough to be familiar with punched cards think
that the standard started with the terminals. And what is with that
bit about "dialing in" over ssh with an 80-column terminal -- if
you're going through ssh, what's it matter what device you're sitting
in front of?
>
> What a wonderful tradition to honor: That of antique electromechanical
> computing devices.
>
Some people still refer to "core memory" and think "core" means
"central" or "basic" or ... something other than ferrite rings.
-- Jim
Josh Suereth
Donald McLean
standards. I know that I've been guilty of that myself.
I don't worry as much any more. If the code isn't formatted the way
that I like it, I just have the IDE reformat. Though currently, I'm
the only one working on my project and I'm using the default settings
for Scala formatting - except line length. The way that I have my
window configured, it's 176 columns wide.
Donald
On Sat, Mar 12, 2011 at 8:03 AM, Josh Suereth <joshua....@gmail.com> wrote:
> I have a nice rant about style in Chapter 3 of Scala In Depth that echoes
> Tony's general premise, albeit with a few more words.
> In general style guides serve three purposes:
> Avoiding Errors
> Code Discovery
> Code Readability/Uniformity
> The last only being 'necessary' when there are lots of developers and
> coralling a cultural norm of coding style is hard, so you need to formalize
> it in writing (something to avoid, if you can help it as once it's written
> it becomes inflexible).
> As for the 80 character limit, I would put this in the last of those three
> style purposes, which is the most apt to 'holy war' status.
> My personal code tends to prefer keeping lines short partly due to habit,
> because at work I must keep things below 80 characters.
> I'd say get away with keeping them as long as you can giving your situation.
--
Family photographs are a critical legacy for
ourselves and our descendants. Protect that
legacy with a digital backup and recovery plan.
For more information, follow my blog:
Kevin Wright
Kevin Wright
gtalk / msn : kev.lee...@gmail.com
Daniel Kristensen
Peter C. Chapin
> I don't worry as much any more. If the code isn't formatted the way that I
> like it, I just have the IDE reformat.
One does need to be cautious about blanket reformatting in a project
involving multiple developers. If there isn't agreement on the format and
everyone just pushes a button to get his or her own format, it can create a
lot of distracting noise in the change diffs.
I contribute to an open source project where the policy is for file-wide
formatting adjustments to go into their own commits. When one has to examine
a diff to understand why something broke it's easy to see the value in such
a policy.
Peter
David Bernard
Philippe Lhoste
> => avoid too many instruction per line
In general, long lines aren't because people put several instructions
per lines (if "instructions" here means "sentence separated by
semi-colon"), but because there is a long function call or a constructor
with many parameters.
Perhaps bad form, but they exist.
I already saw code like:
int aParameterFromConfig =
PropertyProvider.getPropertyProvider().getIntegerProperty(PropertyRepository.THE_PARAMETER_PROPERTY_NAME,
PropertyRepository.THE_DEFAULT_VALUE_OF_THE_PARAMETER);
Really...
In Scala, we also see sequences of collection methods, map, filter,
getOrElse, and similar.
Matthew Pocock
> with no IDE to patch someSuch a quaint scenario. Preposterous, but quaint.
> mission-critical source. On that day, you will owe beer to the devs
> who have made sure their code is correctly indented and fits within
> 80 columns and follows coding conventions.
And only Python and Haskell even have a notion of "correctly indented."
Randall Schulz
Dennis Haupt
-------- Original-Nachricht --------
> Datum: Mon, 14 Mar 2011 16:03:27 +0000
> Von: Matthew Pocock <turingate...@gmail.com>
> An: Randall R Schulz <rsc...@sonic.net>
> CC: scala...@googlegroups.com
> Betreff: Re: [scala-user] Re: Code style: Length of lines
> On 12 March 2011 06:05, Randall R Schulz <rsc...@sonic.net> wrote:
>
> >
> > > with no IDE to patch some
> > > mission-critical source. On that day, you will owe beer to the devs
> > > who have made sure their code is correctly indented and fits within
> > > 80 columns and follows coding conventions.
> >
> > Such a quaint scenario. Preposterous, but quaint.
> >
>
> It's preposterous and quaint until it happens to you. Ever tried to patch
> some code *that has to be fixed now* on an android or iPhone terminal? Is
> it
> going to be easy to read 120 character lines on that form factor? Think
> it's
> practical to boot an IDE and run everything through an auto-indenter in
> this
> situation? I do my primary development with a pair of 30" 2560x1600
> panels,
> but about twice a year have to hot-patch something through an interface
> with
i still think this is ridiculus. i'd refuse to be crippled for 99.9% of the time just because no one bothers to fix the actual problem. providing access to the to-be-fixed code without stupid limitations should be the solution, not limiting the line length.
Jim Balter
<turingate...@gmail.com> wrote:
> On 12 March 2011 06:05, Randall R Schulz <rsc...@sonic.net> wrote:
>>
>> > with no IDE to patch some
>> > mission-critical source. On that day, you will owe beer to the devs
>> > who have made sure their code is correctly indented and fits within
>> > 80 columns and follows coding conventions.
>>
>> Such a quaint scenario. Preposterous, but quaint.
>
> It's preposterous and quaint until it happens to you. Ever tried to patch
> some code *that has to be fixed now* on an android or iPhone terminal? Is it
> going to be easy to read 120 character lines on that form factor? Think it's
> practical to boot an IDE and run everything through an auto-indenter in this
> situation? I do my primary development with a pair of 30" 2560x1600 panels,
> but about twice a year have to hot-patch something through an interface with
> almost no pixels. Sticking to 80 columns helps.
This is not an argument that can be taken seriously. If patching code
from an iPhone, line length is the least of your problems and 80
columns is completely arbitrary, having no relationship to the device,
unlike the Braille readers, which aren't a good argument either but
are a lot better than this one.
-- Jim
Matthew Pocock
i still think this is ridiculus. i'd refuse to be crippled for 99.9% of the time just because no one bothers to fix the actual problem.
providing access to the to-be-fixed code without stupid limitations should be the solution, not limiting the line length.
Jim Balter
<turingate...@gmail.com> wrote:
> comforting [...] boundaries
That is what it seems to come down to.
-- Jim
Rex Kerr
i still think this is ridiculus. i'd refuse to be crippled for 99.9% of the time just because no one bothers to fix the actual problem.Do you feel crippled by sticking within 80 columns
Yes, absolutely.
Sometimes you start
an idea and it's easier to follow
it if it's all on one line.
Don't you think?
80 characters is not consistently enough unless one uses very short variable and method names, and doesn't have very deep nesting. Depending on the code I'm working on, 80 can either be more than adequate or feel hopelessly limiting.
and indenting your code consistently?
No, not at all. Consistent indentation of code is helpful in the _same way that breaking 80 columns is helpful_. That is, it lets you consolidate ideas in a visually instructive manner.
(Incidentally, vim will soft-wrap lines for you; 80+ character problem solved, for the occasional quick fix remotely.)
--Rex
