subject:"On 80 columns should \(not\) be enough for everyone"

Re: (Was: On 80 columns should (not) be enough for everyone)

2011-02-10 Thread Bruno Medeiros


On 30/01/2011 18:55, Tomek Sowiński wrote:

Andrej Mitrovic napisał:


If you really want to set up a column limit that *everyone* has to abide to, 
then make a poll to see what everyone can agree on.


Actually that's a splendid idea. Let's take it easy. Regardless of that silly 
beef I'm really curious what distribution will emerge.

What is your preferred *maximum* length for a line of D code? (please reply 
with a number only)



My preferred maximum length for Java is 120. I haven't coded much D to 
have an opinion about the length for D, but I would suspect it would be 
more or less the same:
Yes, on many things D code lines will have shorter length than Java (you 
can have free functions, you have the auto declarator for variables, 
you have scope statements, etc.), but on other things D code might have 
more (const/immutable and other attributes, like pure, @safe, etc., etc.).



But in any case this poll is only an informative curiosity. It does not 
make sense for it to affect Phobos's style standards, it is the 
(weighted) opinion of the Phobos/Druntime developers that should matter, 
of course.



--
Bruno Medeiros - Software Engineer

Re: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)

2011-02-10 Thread Bruno Medeiros


On 31/01/2011 17:01, Ulrik Mikaelsson wrote:


Now, what we need is the audio-equivalent of this:
http://www.youtube.com/watch?v=6NcIJXTlugc


Damn, pretty damn impressive!

--
Bruno Medeiros - Software Engineer

Re: On 80 columns should (not) be enough for everyone

2011-02-01 Thread Bernard Helyer

Here's SDC, just for kicks:

[SDC]$ find src/sdc -name *.d -print0 | xargs --null wc -l | sort -rn | 
head -n 1
 12545 total
[SDC]$ find src/sdc -name *.d -print0 | xargs --null grep '.\{81,\}' | 
cut -f1 -d:| uniq -c | sort -nr
 81 src/sdc/gen/value.d
 44 src/sdc/gen/expression.d
 35 src/sdc/lexer.d
 26 src/sdc/gen/base.d
 24 src/sdc/parser/declaration.d
 24 src/sdc/gen/declaration.d
 19 src/sdc/gen/sdctemplate.d
 16 src/sdc/gen/statement.d
 13 src/sdc/global.d
 12 src/sdc/gen/sdcfunction.d
 11 src/sdc/sdc.d
  9 src/sdc/gen/sdcpragma.d
  8 src/sdc/parser/expression.d
  8 src/sdc/parser/base.d
  8 src/sdc/gen/sdcmodule.d
  7 src/sdc/parser/conditional.d
  7 src/sdc/gen/attribute.d
  6 src/sdc/parser/sdcimport.d
  6 src/sdc/parser/attribute.d
  6 src/sdc/extract/base.d
  4 src/sdc/parser/sdctemplate.d
  4 src/sdc/parser/enumeration.d
  4 src/sdc/gen/sdcimport.d
  4 src/sdc/gen/enumeration.d
  3 src/sdc/sdc4de.d
  2 src/sdc/token.d
  2 src/sdc/gen/type.d
  2 src/sdc/gen/cfg.d
  2 src/sdc/gen/aggregate.d
  1 src/sdc/tokenstream.d
  1 src/sdc/terminal.d
  1 src/sdc/source.d
  1 src/sdc/parser/statement.d
  1 src/sdc/parser/sdcpragma.d
  1 src/sdc/parser/sdcclass.d
  1 src/sdc/parser/aggregate.d
  1 src/sdc/ast/statement.d
  1 src/sdc/ast/expression.d

Re: On 80 columns should (not) be enough for everyone

2011-02-01 Thread Stewart Gordon


On 31/01/2011 17:54, Ulrik Mikaelsson wrote:
snip

One special-case which often cause problems, is function-calls,
especially method-calls. Roughly lines like: (note 3-level leading
indent)
 otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config, this.context);

At this point, I can see two obvious alternatives;
 otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config,
   this.context);
vs.
 otherObj1.doSomethingSensible(otherObj2.internalVariable,
   this.config,
   this.context);


If only your newsreader were also set to wrap at 90, it would be clearer.

Why align the continuation lines with the open bracket?  I think the shortness of lines 
resulting therefrom is the root cause of what you say next:



Both have advantages and problems. In the first alternative, you might
miss the second argument if reading too fast, and in the second
alternative, the vertical space can be quickly wasted, especially if
the line get's just slightly too long due to many small arguments.

snip

If OTOH you stick to a standard number of spaces by which to indent, which generally 
allows multiple arguments to fit on one line


 otherObj1.doSomethingSensible(otherObj2.internalVariable,
   this.config, this.context);

you don't lead people into the trap of seeing one argument per line.

That said, I've probably in my time done something similar to your example.  And at other 
times, I might do


 otherObj1.doSomethingSensible(
   otherObj2.internalVariable,
   this.config,
   this.context
 );

Stewart.

Re: On 80 columns should (not) be enough for everyone

2011-02-01 Thread Kagamin

Russel Winder Wrote:

 Just because anyone over 50 (like me) has worsening eyesight doesn't
 mean they can't work quite happily with 110 character lines using 8pt
 fonts.  I like 110 character lines in smaller fonts, and I like 2 space
 indents.  And proportional fonts -- Ocean Sans MT rules -- why all this
 monospace font obsession (*).

I use Verdana 15pt (monospaced fonts don't really scale to this extent and 
usually don't have characters beyond ASCII). Pixels are small and displays are 
big nowadays, my editor can accomodate 150 columns in windowed mode.

Re: (Was: On 80 columns should (not) be enough for everyone)

2011-01-31 Thread Don


Tomek Sowiński wrote:

Andrej Mitrovic napisał:


If you really want to set up a column limit that *everyone* has to abide to, 
then make a poll to see what everyone can agree on.


Actually that's a splendid idea. Let's take it easy. Regardless of that silly 
beef I'm really curious what distribution will emerge.

What is your preferred *maximum* length for a line of D code? (please reply 
with a number only)


100 (8 levels of 4-space indent, + 65 characters).
Second preference: 110.

Re: On 80 columns should (not) be enough for everyone

2011-01-31 Thread Max Samukha

On 01/30/2011 07:17 PM, Andrej Mitrovic wrote:

The unittest topic is about to get derailed so I want to continue this silly
discussion here.

Wheres Nick? I want to see the CRT vs LCD discussion heated up again with
Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough
for everyone.

80 colums is an artifact of the old age. Just like the preprocessor is an
artifact of the C language. And many other old things are artifacts. There's no
reason to keep these artifacts around anymore.

A couple of things, Andrei:
1. 80 colums is way too restrictive. 80 columns wasn't determined by some
scientific method to be a good size for code, it's a product of limitations of
the older generation hardware. Who will run a brand new language like D in a
freakin' Terminal?

Have you ever heard of the expression limitations boost creativity? That can be
considered a good thing, if creativity is what you're after. In code, it's not. You're looking for
clarity in code. 80 column limitations are good for C obfuscation contests and nothing else. 80
columns means people are going to *work around* the limit, by using hacks and workarounds to make
everything fit in place. Do you really believe that programmers are going to spend any time at all
thinking: *oh this line doesn't fit on 80 columns. I should now spend some time thinking
about how to improve and rewrite the design of my code. 80 columns really is the golden
ration*?

If you want to see more files on the screen, get multiple screens. Is Facebook
running out of money, can't they afford a few monitors for the C++ guru? Yes, I
know you're not allowed to comment on that one. :)

2. A widescreen aspect ratio causes less eye strain. Wider code means the same.
It doesn't have to stretch all the way to be effective, but 80 columns is too
limiting. Do a Google search and read what people have go say about that.

3. Less columns means more rows. And generally coders *hate* it when they can't
see a function that fits on a single screen. They hate having to scroll up and
down. This common syntax form is a proof of that:
void main() {
void foo() {
while (true) {
if (done) {
}
}
}
}

I find that unpleasant to read. Not impossible, but unpleasant. I can live with
it though, but if you limit code to 80 limits that's going to become a mess to
read.

3. It's 2010. Does your GNU/emacs still not support wrapping lines by word
boundaries? Scite had this since the '90s, and that's not even an advanced
editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can
customize it to wrap on whatever boundary you want to (although I'm only
speculating, but pretty much everything in Vim is customizable). You can even
customize how your cursor reacts if it's on an 'artificial' new line, one that
has been wrapped.

Isn't technology amazing?

4. Just how many files do you want to edit at a single time on the screen?
We're not really multitasking beings, you know. Try using one of your hands and
do forward circles, as if it were a wheel. With the other one do backward
circles. And now use your foot to draw a circle on the floor. You're end up
looking like a clown in seconds, and a bad one at that.

Again, people who want to have documentation, and code, and IRC chats in
display buy more computer screens. Why should your code have to suffer if you
really want to do multiple things all at once?

Bottom line:

If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on. I don't see why everyone
has to cater to your rules only, regardless of what your professional
experience might be. You're a big contributor to Phobos, but you're not the
only one. I tend to believe that D is (or should be) a community effort, so
please don't hijack D away from the community by forcing your own rules down to
everyone else.

1 2 >

1 - 100 of 105 matches

Mail list logo