www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - On 80 columns should (not) be enough for everyone

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jan 30 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Also, it's 2011 apparently. I'm still stuck in 2010 it seems. :p
Jan 30 2011
prev sibling next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrej Mitrovic wrote:


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


 

 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.


Yes, but there has to be some limit, horizontal scrolling is much worse. 
Someone at my workplace likes to make 400+ columns lines of code for 
example, he likes it but it confuses the shit out of me.
 

 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?


Terminals can host more than 80 columns these days.


 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. :)


iirc Andrei commented facebook installed him a 30inch screen.
Jan 30 2011
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 30/01/11 5: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.

<snip>


Is this really worth arguing about?

Just stick to 80 columns. It's not a big deal.
Jan 30 2011
next sibling parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 01/30/2011 01:01 PM, Peter Alexander wrote:

 On 30/01/11 5: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.

 <snip>


 Is this really worth arguing about?

 Just stick to 80 columns. It's not a big deal.


One argument that I can think of is to at least raise the number of
allowed columns. Why? Well, phobos' names like tr will be (or are)
refactored to translate and with camelcase we encourage people to use
descriptive names. And with template parameters and everything I do not
want to call functions, putting 1 argument on every line. I'd suggest
raising it to 120 or 150...
Jan 30 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:


 Is this really worth arguing about?


You are right, let's stick to 90-95 columns and let's close this discussion.

Bye,
bearophile
Jan 30 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 12:25 PM, bearophile wrote:

 Peter Alexander:


 Is this really worth arguing about?


 You are right, let's stick to 90-95 columns and let's close this discussion.


I, too, would love to vote how others should format their code. FWIW 
here's a data point:

$ wc -l std/**/*.d
  138793 total
$ grep '.\{81,\}' std/**/*.d | cut -f1 -d:| uniq -c | sort -nr
    6742 std/datetime.d
     145 std/bind.d
     116 std/base64.d
     106 std/windows/registry.d
      92 std/file.d
      81 std/socket.d
      67 std/internal/math/biguintcore.d
      66 std/math.d
      64 std/conv.d
      60 std/regexp.d
      54 std/internal/math/gammafunction.d
      51 std/numeric.d
      35 std/stream.d
      34 std/internal/math/biguintx86.d
      32 std/regex.d
      30 std/traits.d
      22 std/container.d
      21 std/zip.d
      21 std/random.d
      21 std/format.d
      21 std/algorithm.d
      19 std/signals.d
      18 std/utf.d
      18 std/string.d
      18 std/internal/math/errorfunction.d
      16 std/loader.d
      14 std/typelist.d
      14 std/internal/math/biguintnoasm.d
      13 std/typecons.d
      12 std/range.d
      12 std/concurrency.d
      11 std/json.d
      11 std/date.d
      10 std/functional.d
      10 std/c/windows/winsock.d
      10 std/bigint.d
       9 std/encoding.d
       7 std/path.d
       6 std/zlib.d
       6 std/xml.d
       6 std/outbuffer.d
       5 std/stdio.d
       5 std/mathspecial.d
       5 std/array.d
       4 std/variant.d
       4 std/typetuple.d
       4 std/mmfile.d
       4 std/md5.d
       4 std/cpuid.d
       3 std/socketstream.d
       3 std/process.d
       3 std/getopt.d
       3 std/dateparse.d
       3 std/ctype.d
       2 std/windows/charset.d
       2 std/uri.d
       2 std/uni.d
       2 std/stdarg.d
       2 std/c/stdlib.d
       2 std/c/osx/socket.d
       2 std/compiler.d
       2 std/c/linux/socket.d
       1 std/windows/syserror.d
       1 std/windows/iunknown.d
       1 std/system.d
       1 std/stdiobase.d
       1 std/stdint.d
       1 std/__fileinit.d
       1 std/exception.d
       1 std/demangle.d
       1 std/datebase.d
       1 std/c/windows/com.d
       1 std/cstream.d
       1 std/complex.d
       1 std/bitmanip.d
       1 Binary file std/perf.d matches


Andrei
Jan 30 2011
parent Bernard Helyer <b.helyer gmail.com> writes:
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
Feb 01 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:

 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.


80 columns came from how many characters would fit on a standard size 8.5*11 
sheet of paper. Even punch cards followed this precedent.

That paper size has stood the test of time as being a comfortable size for 
reading. Reading longer lines is fatiguing, as when one's eyes "carriage
return" 
they tend to go awry.

You can see this yourself if you resize and reflow a text web site to be 
significantly wider than 80 columns. It gets harder to read.
Jan 30 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 12:27 PM, Walter Bright wrote:

 Andrej Mitrovic wrote:

 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.


 80 columns came from how many characters would fit on a standard size
 8.5*11 sheet of paper. Even punch cards followed this precedent.

 That paper size has stood the test of time as being a comfortable size
 for reading. Reading longer lines is fatiguing, as when one's eyes
 "carriage return" they tend to go awry.

 You can see this yourself if you resize and reflow a text web site to be
 significantly wider than 80 columns. It gets harder to read.


Also: pick a random book or newspaper and count the characters in a 
line. They range between 60 and 80, counting for about 10 words per 
line. This has been the case ever writing systems have been invented. It 
is a fallacy to assume that 80 has anything to do with the first 
monitors. In fact, it's the opposite - the monitors were conceived 
following a universal human constant.

One funny thing is that at my employer (where each and every employee 
has a 30" 2560x1600 monitor) everything is under constant debate, 
starting with which email server and ending with choosing UserId versus 
UserID. Nobody and not once has debated the 80 column rule.

Phobosians have voted with their fingers. Long lines in Phobos are rare 
and the result of lack of enforcement, not a stylistic choice. Jonathan 
simply didn't know about that, and has graciously agreed to align to 
that convention (thanks!).


Andrei
Jan 30 2011
next sibling parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
click delete now)

I'm not sure whether text-books and program-code are really comparable
in this respect. When reading books I hardly put much attention to
each particular word, while in computer-code, each token is very
significant. The "flow" of reading is simply different. If it weren't,
we would hardly use hard line-breaks at all, just concatenate
statements like we concatenate sentences in text, and use <your word
processor> to format code. Especially, we would not use monospaced
fonts and care about "columns".

I would rather like to hear whether any mathematicians ever insert
hard-breaks into their equations just "to not get them too wide".

Personally, I've been a long time on the fence regarding strict
line-length, and my current position is:
 90 columns is the rule of thumb. 80 columns is often hard to fit
using readable names, but 90 columns generally works. When the code
exceeds 90 columns, I try to look for:
 * local variable names that can be shortened without breaking their
descriptiveness.
 * sub-expressions in the line, which can be reasonably be extracted
into separe pre-computed variable. (Which also increases readability
of the code by itself.)
 * unnecessary nested depth in the function, and try to either
refactor parts out to separate functions, or refactor the function to
be more pass-based rather then nested.

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);

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.
(I.E. debug-output of many short-named local variables.) In these
cases, I usually just leave it to overflow. That will
 * hint to the reader that it's still just one single function-call
 * arguments won't be missed
 * not waste unnecessary vertical space
 * it's up to the code-viewer to determine whether a line-wrap is
actually needed, which it might even indicate using a wrap-marker in
the margin (not possible with a manual line-break).

For other common long-line sources like enums, array literals etc, I
usually block-format and insert line-breaks as usual to not exceed 90
columns wide.

My guess is, if I worked enough with long mathematical expression, I
would use roughly the same guidelines.

/ Ulrik

(*doh* that was probably more than 2 cents worth.)

2011/1/30 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 01/30/2011 12:27 PM, Walter Bright wrote:

 Andrej Mitrovic wrote:

 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.


 80 columns came from how many characters would fit on a standard size
 8.5*11 sheet of paper. Even punch cards followed this precedent.

 That paper size has stood the test of time as being a comfortable size
 for reading. Reading longer lines is fatiguing, as when one's eyes
 "carriage return" they tend to go awry.

 You can see this yourself if you resize and reflow a text web site to be
 significantly wider than 80 columns. It gets harder to read.


 Also: pick a random book or newspaper and count the characters in a line.
 They range between 60 and 80, counting for about 10 words per line. This has
 been the case ever writing systems have been invented. It is a fallacy to
 assume that 80 has anything to do with the first monitors. In fact, it's the
 opposite - the monitors were conceived following a universal human constant.

 One funny thing is that at my employer (where each and every employee has a
 30" 2560x1600 monitor) everything is under constant debate, starting with
 which email server and ending with choosing UserId versus UserID. Nobody and
 not once has debated the 80 column rule.

 Phobosians have voted with their fingers. Long lines in Phobos are rare and
 the result of lack of enforcement, not a stylistic choice. Jonathan simply
 didn't know about that, and has graciously agreed to align to that
 convention (thanks!).


 Andrei
Jan 31 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:

 FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
 click delete now)

 I'm not sure whether text-books and program-code are really comparable
 in this respect. When reading books I hardly put much attention to
 each particular word, while in computer-code, each token is very
 significant. The "flow" of reading is simply different. If it weren't,
 we would hardly use hard line-breaks at all, just concatenate
 statements like we concatenate sentences in text, and use<your word
 processor>  to format code. Especially, we would not use monospaced
 fonts and care about "columns".


Well the fact of the matter is that style used in books is very 
influential. People do copy book samples into code and continue working 
in the same style from them. I've been asked for (and released) the 
source code of all snippets in TDPL.


 I would rather like to hear whether any mathematicians ever insert
 hard-breaks into their equations just "to not get them too wide".


I'm not sure I can qualify as a mathematician but my research is very 
math-heavy. In my thesis 
(http://erdani.com/research/dissertation_color.pdf) I frequently 
inserted line breaks even when not technically necessary, check e.g. eq. 
2.16 on page 12.


 Personally, I've been a long time on the fence regarding strict
 line-length, and my current position is:
   90 columns is the rule of thumb. 80 columns is often hard to fit
 using readable names, but 90 columns generally works.


Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm 
now more inclined to increase and/or soften the recommended limit for 
Phobos.


Andrei
Jan 31 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm 
 now more inclined to increase and/or soften the recommended limit for 
 Phobos.


I think 110 columns are a little too many. I have suggested 90-95 chars max
(but less than 80 on average) after seeing both the problems caused by too much
short lines (to keep lines below 70-80 chars I have seen programmers use 2
spaces to indent or use very short variable names. This is worse than 95 chars
long lines), and seeing lines with 120+ chars that cause troubles to older
programmer that can't use a too much small font because of their older eyes.

Bye,
bearophile
Jan 31 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-01-31 at 13:41 -0500, bearophile wrote:
[ . . . ]

 I think 110 columns are a little too many. I have suggested 90-95
 chars max (but less than 80 on average) after seeing both the problems
 caused by too much short lines (to keep lines below 70-80 chars I have
 seen programmers use 2 spaces to indent or use very short variable
 names. This is worse than 95 chars long lines), and seeing lines with
 120+ chars that cause troubles to older programmer that can't use a
 too much small font because of their older eyes.


What say we cut the agist crap.

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 (*).

At the end of the day source code consistency is the only really
important thing.  Anyone amending a file or adding a file to a codebase
must do it in the style of the current code so as to avoid spoiling
consistency, and creating specious changes in version control.  Just
because I object to a coding style doesn't mean I can't use it if I am
amending someone else code.

Whoever is the project leader for a project defines a style and then
everyone works with it -- even if that style is some crappy 80 column
stupidity ;-)


(*)  Flame wars should be directed to /dev/null -- or if you insist on
using Windows, whatever the equivalent is. :-)
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 31 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Russel Winder:


 What say we cut the agist crap.


There are also armies of programmers with myopia :-)

Bye,
bearophile
Jan 31 2011
prev sibling parent Kagamin <spam here.lot> writes:
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.
Feb 01 2011
prev sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/31 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:

 I'm not sure whether text-books and program-code are really comparable
 in this respect. When reading books I hardly put much attention to
 each particular word, while in computer-code, each token is very
 significant. The "flow" of reading is simply different. If it weren't,
 we would hardly use hard line-breaks at all, just concatenate
 statements like we concatenate sentences in text, and use<your word
 processor> =C2=A0to format code. Especially, we would not use monospaced
 fonts and care about "columns".


 Well the fact of the matter is that style used in books is very influenti=


al.

 People do copy book samples into code and continue working in the same st=


yle

 from them. I've been asked for (and released) the source code of all
 snippets in TDPL.


Sorry, maybe I was unclear, I wasn't referring to code-snippets in a
book. I meant the kind of text-books I understood Walter refer to,
that made the basis for 80x25. Think fiction, not programming books. I
absolutely agree there are good UI-design reasons to limit
column-width in these. Commonly such text is also "text-align:
justify", and even broken up into multiple-column layouts to reduce
horizontal scan, but precisely those two things make me skeptical
about just HOW relevant it actually is for computer-code.


 I would rather like to hear whether any mathematicians ever insert
 hard-breaks into their equations just "to not get them too wide".


 I'm not sure I can qualify as a mathematician but my research is very
 math-heavy. In my thesis (http://erdani.com/research/dissertation_color.p=


df)

 I frequently inserted line breaks even when not technically necessary, ch=


eck

 e.g. eq. 2.16 on page 12.


Thank you, interesting for the topic (although I didn't understand a
thing of the actual math :). I note however that given the very terse
variable-names (as is common in math), the lines don't actually grow
very long. However, where you HAVE chosen to insert line-breaks, is at
equality-operators which I would say is roughly a statement in
programming-language terms. ("A =3D B" is a statement, while "A+B" is
not.)

Interestingly enough, this is roughly the rule-of thumb I use. Try
hard to keep statements below 90 characters, but don't resort to
manual line-breaks if it's not possible.


 Personally, I've been a long time on the fence regarding strict
 line-length, and my current position is:
 =C2=A090 columns is the rule of thumb. 80 columns is often hard to fit
 using readable names, but 90 columns generally works.


 Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm no=


w

 more inclined to increase and/or soften the recommended limit for Phobos.


Actually, writing and reading about it got me thinking. I think the
real value of the 80/90/120/whatever-rule is not really the actual
line-length itself. If that was the case, editors with
auto-indentation could quite easily have additional rules for
automatic code-wraps. The actual value of having the rule is to alert
the coder that something _might_ be sub-optimally expressed. Perhaps D
should have something similar to pylint? Sure, much of the need for
pylint goes away in a statically typed language, but it's also quite
good in diagnosing design by code-complexity measurements. OTOH things
like symbols-per-file, arguments-per-function,
operations-per-function, etc. could be good indicators to quickly spot
hairy code. One could also check for naming-conventions and probably
other cleanliness-aspects as well.
Jan 31 2011
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Feb 01 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/31/2011 06:54 PM, Ulrik Mikaelsson wrote:

I share most of Ulrik mentions.


 I'm not sure whether text-books and program-code are really comparable
 in this respect.


Even if they were (which is imo absurd to state), what would count is not 
column number, but content length -- which is different in the case of code due 
to indentation. Thus, to get 80-char max line length, we'd have to allow up to, 


Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright Wrote:


 Andrej Mitrovic wrote:

 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.


 
 80 columns came from how many characters would fit on a standard size 8.5*11 
 sheet of paper. Even punch cards followed this precedent.
 
 That paper size has stood the test of time as being a comfortable size for 
 reading. Reading longer lines is fatiguing, as when one's eyes "carriage
return" 
 they tend to go awry.
 
 You can see this yourself if you resize and reflow a text web site to be 
 significantly wider than 80 columns. It gets harder to read.


Print text doesn't have indentation levels though.  Assuming a 4 character
indent, the smallest indentation level for code in a D member function is 8
characters.  Add a nested conditional and code is starting 16 characters in,
which when wrapped at 80 characters begins to look like a newspaper column.  I
wrap all my comments at 79 characters, but allow code to spill as far as 110
(which is the number of columns on an 8.5x11" piece of paper in landscape mode).
Jan 30 2011
next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Sean Kelly napisa=C5=82:


 Print text doesn't have indentation levels though.  Assuming a 4 characte=


r indent, the smallest indentation level for code in a D member function is=
 8 characters.  Add a nested conditional and code is starting 16 characters=
 in, which when wrapped at 80 characters begins to look like a newspaper co=
lumn.  I wrap all my comments at 79 characters, but allow code to spill as =
far as 110 (which is the number of columns on an 8.5x11" piece of paper in =
landscape mode).

Yeah. If counted without indents, 90 characters would probably suffice, but=
 with them it's at least 120 so that nested code doesn't get stifled.

And I'm programming with a proportional font -- far more readable than a mo=
no-space.

--=20
Tomek
Jan 30 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 01:20 PM, Sean Kelly wrote:

 Walter Bright Wrote:


 Andrej Mitrovic wrote:

 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.


 80 columns came from how many characters would fit on a standard size 8.5*11
 sheet of paper. Even punch cards followed this precedent.

 That paper size has stood the test of time as being a comfortable size for
 reading. Reading longer lines is fatiguing, as when one's eyes "carriage
return"
 they tend to go awry.

 You can see this yourself if you resize and reflow a text web site to be
 significantly wider than 80 columns. It gets harder to read.


 Print text doesn't have indentation levels though.


It does - bulleted and numbered lists, certain sidebars, block quotes.


 Assuming a 4 character indent, the smallest indentation level for
 code in a D member function is 8 characters.  Add a nested
 conditional and code is starting 16 characters in, which when wrapped
 at 80 characters begins to look like a newspaper column.


Newspaper columns are strongly optimized for being read quickly. Not a 
bad standard I guess.

I don't contend that your choice works for you, but I refute this 
particular rationalisation of it. Indentation should NOT be discounted 
as a participant to the maximum line width. If anything it adds 
overhead, not reduces it.


Andrei
Jan 30 2011
parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:


 On 01/30/2011 01:20 PM, Sean Kelly wrote:

 Walter Bright Wrote:


 Andrej Mitrovic wrote:

 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.


 80 columns came from how many characters would fit on a standard size 8.5*11
 sheet of paper. Even punch cards followed this precedent.

 That paper size has stood the test of time as being a comfortable size for
 reading. Reading longer lines is fatiguing, as when one's eyes "carriage
return"
 they tend to go awry.

 You can see this yourself if you resize and reflow a text web site to be
 significantly wider than 80 columns. It gets harder to read.


 Print text doesn't have indentation levels though.


 
 It does - bulleted and numbered lists, certain sidebars, block quotes.


True.  Though multiply nested such blocks are rare.
 

 Assuming a 4 character indent, the smallest indentation level for
 code in a D member function is 8 characters.  Add a nested
 conditional and code is starting 16 characters in, which when wrapped
 at 80 characters begins to look like a newspaper column.


 
 Newspaper columns are strongly optimized for being read quickly. Not a 
 bad standard I guess.
 
 I don't contend that your choice works for you, but I refute this 
 particular rationalisation of it. Indentation should NOT be discounted 
 as a participant to the maximum line width. If anything it adds 
 overhead, not reduces it.


I just said that indentation reduces available space for code.  How is that
discounting it?  That aside, I don't know that the comparison to newspaper
columns really holds.  Sentences wrap naturally, while I'm not sure the same
holds for a code statement--consider languages that require one statement per
line.  At the very least, wrapping a statement often requires additional
consideration to line up related sections to ease readability.  That isn't to
say that I think a programmer should pack as much as possible into a line of
code.  Quite the contrary, in fact.  I'm simply relating my experience with
having a hard 80 column break, which is something I used to do religiously.
Jan 30 2011
prev sibling next sibling parent reply JMRyan <nospam nospam.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote in
news:ii4an2$1npj$1 digitalmars.com: 


 80 columns came from how many characters would fit on a standard size
 8.5*11 sheet of paper. Even punch cards followed this precedent.


This suggests (without exactly stating) one of my personal reasons for a
strict line length limit:  sometimes programmers like to print their
code.   Maybe I'm showing my age, but I find dead trees best for code
review.  One *can* use a smaller font (hard on the eyes) or print in
landscape (yuck--and even that is not enough for some code).

PS.  I knew about the punch card precident and have even used key punch
machines myself, but I didn't know that punch card length was based on
earlier precident.  Given the absurd length of line printer output of
the day, that surprises me.
Jan 31 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
JMRyan wrote:

 Walter Bright <newshound2 digitalmars.com> wrote in
 news:ii4an2$1npj$1 digitalmars.com: 
 

 80 columns came from how many characters would fit on a standard size
 8.5*11 sheet of paper. Even punch cards followed this precedent.


 
 This suggests (without exactly stating) one of my personal reasons for a
 strict line length limit:  sometimes programmers like to print their
 code.   Maybe I'm showing my age, but I find dead trees best for code
 review.  One *can* use a smaller font (hard on the eyes) or print in
 landscape (yuck--and even that is not enough for some code).
 
 PS.  I knew about the punch card precident and have even used key punch
 machines myself, but I didn't know that punch card length was based on
 earlier precident.  Given the absurd length of line printer output of
 the day, that surprises me.


Looking it up shows that the history is a bit more complicated than I said:

http://en.wikipedia.org/wiki/Hollerith_card

http://en.wikipedia.org/wiki/Characters_per_line
Jan 31 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 07:27 PM, Walter Bright wrote:

 Andrej Mitrovic wrote:

 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.


 80 columns came from how many characters would fit on a standard size 8.5*11
 sheet of paper. Even punch cards followed this precedent.

 That paper size has stood the test of time as being a comfortable size for
 reading. Reading longer lines is fatiguing, as when one's eyes "carriage
 return" they tend to go awry.

 You can see this yourself if you resize and reflow a text web site to be
 significantly wider than 80 columns. It gets harder to read.


Code is no newspaper article. And newspaper articles are rarely multi-indented.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Andrej Mitrovic napisa=C5=82:


 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 sil=
ly 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)

--=20
Tomek
Jan 30 2011
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Tomek Sowi=C5=84ski wrote:

 Andrej Mitrovic napisa=C5=82:
=20

 If you really want to set up a column limit that *everyone* has to abi=




de to, then make a poll to see what everyone can agree on.

=20
 Actually that's a splendid idea. Let's take it easy. Regardless of that=


 silly beef I'm really curious what distribution will emerge.

=20
 What is your preferred *maximum* length for a line of D code? (please r=


eply with a number only)

=20


	I use 70.

	May occasionally be extended to 80 if there is no easy way to
reflow the code below 70, but never above 80.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 30 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 12:55 PM, 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.


Agreed. FWIW I'm ready to go with anything that Phobos heavyweights vote.


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


80.


Andrei
Jan 30 2011
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Tomek Sowiński Wrote:

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


110
Jan 30 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Tomek Sowi=C5=84ski napisa=C5=82:


 What is your preferred *maximum* length for a line of D code? (please rep=


ly with a number only)

120.

--=20
Tomek
Jan 30 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Tomek Sowiński wrote:

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


6.022e+23
Jan 30 2011
next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Walter Bright napisa=C5=82:


 What is your preferred *maximum* length for a line of D code? (please r=




eply with a number only) =20

=20
 6.022e+23


That's a whole mole of code! ;-)

--=20
Tomek
Jan 30 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jan 2011 14:47:26 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Tomek Sowiński wrote:

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


 6.022e+23


It's amazing that D does so much, and to top it off, it's only ONE LINE OF  
CODE!

-Steve
Jan 31 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Tomek Sowi=C5=84ski <just ask.me> wrote:


 Andrej Mitrovic napisa=C5=82:


 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 tha=


t  =


 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)


80 columns of code. Indents may change that slightly.


-- =

Simen
Jan 30 2011
prev sibling next sibling parent reply foobar <foo bar.com> writes:
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)
 
 -- 
 Tomek
 


I think that putting an artificial limit is incredibly stupid. Haven't anyone
here learned the "No magic numbers" rule?!?!

Walter correctly pointed out that it's harder to read long rows, however,
unlike printed text and ancient terminals, current display technology is much
more dynamic. 
Font size, zoom level, screen form-factor, window size, resolution, etc means
that each person can configure his own individual optimal view. 

As the OP said, use word wrap and adjust your editor window width/font
size/zoom level/etc to your liking. 
If your editor does not support this "new" feature, go get a new editor and
don't bother other people with different preferences.
Stop forcing this moronic "one size fits all" attitude on everyone.
Jan 30 2011
next sibling parent reply so <so so.do> writes:
 I think that putting an artificial limit is incredibly stupid. Haven't  
 anyone here learned the "No magic numbers" rule?!?!

 Walter correctly pointed out that it's harder to read long rows,  
 however, unlike printed text and ancient terminals, current display  
 technology is much more dynamic.
 Font size, zoom level, screen form-factor, window size, resolution, etc  
 means that each person can configure his own individual optimal view.

 As the OP said, use word wrap and adjust your editor window width/font  
 size/zoom level/etc to your liking.
 If your editor does not support this "new" feature, go get a new editor  
 and don't bother other people with different preferences.
 Stop forcing this moronic "one size fits all" attitude on everyone.


I agree, but i guess they are talking about standard library.
Jan 30 2011
parent reply foobar <foo bar.com> writes:
so Wrote:


 I think that putting an artificial limit is incredibly stupid. Haven't  
 anyone here learned the "No magic numbers" rule?!?!

 Walter correctly pointed out that it's harder to read long rows,  
 however, unlike printed text and ancient terminals, current display  
 technology is much more dynamic.
 Font size, zoom level, screen form-factor, window size, resolution, etc  
 means that each person can configure his own individual optimal view.

 As the OP said, use word wrap and adjust your editor window width/font  
 size/zoom level/etc to your liking.
 If your editor does not support this "new" feature, go get a new editor  
 and don't bother other people with different preferences.
 Stop forcing this moronic "one size fits all" attitude on everyone.


 
 I agree, but i guess they are talking about standard library.


Right, so does that mean it should be made _less_ readable by a diverse
community of people? 
I have no issue with any style Andrei or others use when they code for
themselves, be it 10 characters per row or 1000. 
I do place a MUCH higher weight on making the stdlib readable and accessible
for a large range of diverse people with different cultures, languages,
traditions, eye-sight, screen sizes, and preferred beer flavors.

ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which is
by far one of worst ever. 

"new-age" scripting languages such as python and Ruby and languages that were
designed to be readable by humans such as Smalltalk.
Jan 30 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
foobar wrote:

 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which

 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.


I think you've mixed up libraries with languages. Please rephrase so we know 
what you're referring to and give specifics.
Jan 30 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail Erdani.org> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article

 foobar wrote:

 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which

 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.


 I think you've mixed up libraries with languages. Please rephrase so we know
 what you're referring to and give specifics.


Seconded. Also there is this one presupposition that reflects poorly on
foobar's argument: that choosing foobar's
preferred convention inherently makes the code more accessible. In fact, a
stronger argument could be made to
the contrary as we're talking about a maximum and 80 < 120.

Andrei from the ER
Jan 30 2011
parent reply foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:


 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 foobar wrote:

 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which

 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.


 I think you've mixed up libraries with languages. Please rephrase so we know
 what you're referring to and give specifics.


 
 Seconded. Also there is this one presupposition that reflects poorly on
foobar's argument: that choosing foobar's
 preferred convention inherently makes the code more accessible. In fact, a
stronger argument could be made to
 the contrary as we're talking about a maximum and 80 < 120.
 
 Andrei from the ER


That's just incorrect since I didn't even specify my style convention.
As I said multiple times before, Phobos is design with Andrei in mind: meaning
that if you are Andrei-like (or if you _are_ indeed Andrei) it would be easy to
read and use. Otherwise it confusing as hell and hard to navigate. 

In addition, you now want to force artificial limits that don't make any sense. 

You completely miss the most important principle - it doesn't matter how good
and efficient your product is if no one's using it. Phobos is a very good
product that I for one will never use. Just looking at the one huge page for
algorithms is enough to discourage many people.
Jan 30 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-31 02:18:26 -0500, foobar <foo bar.com> said:


 Phobos is a very good product that I for one will never use. Just 
 looking at the one huge page for algorithms is enough to discourage 
 many people.


But is Phobos the problem or is the one-page-per-module documentation 
the problem?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 31 2011
parent foobar <foo bar.com> writes:
Michel Fortin Wrote:


 On 2011-01-31 02:18:26 -0500, foobar <foo bar.com> said:
 

 Phobos is a very good product that I for one will never use. Just 
 looking at the one huge page for algorithms is enough to discourage 
 many people.


 
 But is Phobos the problem or is the one-page-per-module documentation 
 the problem?
 
 -- 
 Michel Fortin
 michel.fortin michelf.com
 http://michelf.com/
 


Phobos' organization is the problem. If you read the C++ standard you'll see
that their description of the stdlib describes <algorithm> as a library. Hence,
c++'s design is a single file per library. Phobos does exactly the same mistake.

D has a far superior module system that doesn't require this moronic design.
Please let's use it. 

I have a hard time believing that having a separate doc page per function is a
better solution than to properly organize the code.
Jan 31 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/31/2011 01:18 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 foobar wrote:

 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which

 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.


 I think you've mixed up libraries with languages. Please rephrase so we know
 what you're referring to and give specifics.


 Seconded. Also there is this one presupposition that reflects poorly on
foobar's argument: that choosing foobar's
 preferred convention inherently makes the code more accessible. In fact, a
stronger argument could be made to
 the contrary as we're talking about a maximum and 80<  120.

 Andrei from the ER


 That's just incorrect since I didn't even specify my style convention.
 As I said multiple times before, Phobos is design with Andrei in mind: meaning
that if you are Andrei-like (or if you _are_ indeed Andrei) it would be easy to
read and use. Otherwise it confusing as hell and hard to navigate.


But that goes for anyone, including your code. Code written in foobar's 
style is designed with foobar in mind: meaning that if you are 
foobar-like (or if you _are_ indeed foobar) it would be easy to read and 
use. Otherwise it is confusing as hell and hard to navigate.

I can only assume you'd have a hard time writing code that does not have 
foobar's signature. Same here.

Besides, it seems to have worked for me; at work I'm not considered one 
of the more obfuscated coders. Also, I wrote a little library Loki which 
is regarded as very small and readable for what it does. Its 
functionality has been shadowed by the much larger and comprehensive 
Boost, but Loki's code has always been the simplest and cleanest 
although it implements rather advanced concepts. Do you have any 
publicly available samples of your work that we might look at?


 In addition, you now want to force artificial limits that don't make
 any sense.

 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.


 From what I've seen, everyone who advocates D2 mentions std.algorithm 
as one of its main strengths, and never as a liability. I have 
difficulty reconciling that signal with one opinion relayed anonymously.


Andrei
Jan 31 2011
next sibling parent reply foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:


 On 01/31/2011 01:18 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 foobar wrote:

 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which

 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.


 I think you've mixed up libraries with languages. Please rephrase so we know
 what you're referring to and give specifics.


 Seconded. Also there is this one presupposition that reflects poorly on
foobar's argument: that choosing foobar's
 preferred convention inherently makes the code more accessible. In fact, a
stronger argument could be made to
 the contrary as we're talking about a maximum and 80<  120.

 Andrei from the ER


 That's just incorrect since I didn't even specify my style convention.
 As I said multiple times before, Phobos is design with Andrei in mind: meaning
that if you are Andrei-like (or if you _are_ indeed Andrei) it would be easy to
read and use. Otherwise it confusing as hell and hard to navigate.


 
 But that goes for anyone, including your code. Code written in foobar's 
 style is designed with foobar in mind: meaning that if you are 
 foobar-like (or if you _are_ indeed foobar) it would be easy to read and 
 use. Otherwise it is confusing as hell and hard to navigate.
 
 I can only assume you'd have a hard time writing code that does not have 
 foobar's signature. Same here.
 
 Besides, it seems to have worked for me; at work I'm not considered one 
 of the more obfuscated coders. Also, I wrote a little library Loki which 
 is regarded as very small and readable for what it does. Its 
 functionality has been shadowed by the much larger and comprehensive 
 Boost, but Loki's code has always been the simplest and cleanest 
 although it implements rather advanced concepts. Do you have any 
 publicly available samples of your work that we might look at?
 

 In addition, you now want to force artificial limits that don't make
 any sense.

 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.


 
  From what I've seen, everyone who advocates D2 mentions std.algorithm 
 as one of its main strengths, and never as a liability. I have 
 difficulty reconciling that signal with one opinion relayed anonymously.
 
 
 Andrei


Everything is relative. Loki is a c++ library and I'm sure it's one of the best
c++ libs. This is relative to a horribly unfriendly language which is used by a
certain type of people. 
I'm OTOH comparing to a different set of languages, their libs and their users. 

Also, I never said that Phobos is poor from an implementation point of view, on
the contrary, I too think that especially the new phobos modules (Algorithms)
and concepts (Range) are very good and efficient. 

My reoccurring complain is about _usability_ of this awesome code base. 
The code is poorly organized in few huge files, functions are poorly named,
etc. 

I keep taking about the API while you keep talking about its implementation.
 D needs to cater for different kinds of people, not just American born C++
guru programmers, but a diverse community of programmers with different
programming backgrounds (that includes web developers that only learned
scripting languages), different nationalities (They don't need to have native
level English capabilities including understanding of American culture and
insider jokes), different OS users (not just *nix geeks), etc.
Jan 31 2011
parent spir <denis.spir gmail.com> writes:
On 01/31/2011 07:38 PM, foobar wrote:

 I keep taking about the API while you keep talking about its implementation.
   D needs to cater for different kinds of people, not just American born C++
guru programmers, but a diverse community of programmers with different
programming backgrounds (that includes web developers that only learned
scripting languages), different nationalities (They don't need to have native
level English capabilities including understanding of American culture and
insider jokes), different OS users (not just *nix geeks), etc.


+++

(insider jokes are excluding jokes)

(I'm unsure about tolerating Heineken drinkers, though)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 01/31/2011 01:18 AM, foobar wrote:



 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.


  From what I've seen, everyone who advocates D2 mentions std.algorithm  
 as one of its main strengths, and never as a liability. I have  
 difficulty reconciling that signal with one opinion relayed anonymously.


I think the main problem is with ddoc.  This, from std.algorithm is a  
f**king mess IMO:

Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference  
SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter  
SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront  
canFind completeSort copy count endsWith equal fill filter find  
findAdjacent findAmong group indexOf initializeAll insert isPartitioned  
isSorted largestPartialIntersection largestPartialIntersectionWeighted  
levenshteinDistance levenshteinDistanceAndPath makeIndex map max min  
minCount minPos mismatch move moveAll moveSome nWayUnion no none  
partialSort partition reduce remove reverse schwartzSort semistable  
setDifference setIntersection setSymmetricDifference setUnion skipOver  
sort splitter stable startsWith substitute swap swapRanges topN topNCopy  
uninitializedFill uniq unstable until yes

(in voice of comic-book guy) Worst navigation bar ever.

-Steve
Jan 31 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/31/11 1:07 PM, Steven Schveighoffer wrote:

 On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 01/31/2011 01:18 AM, foobar wrote:



 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.


 From what I've seen, everyone who advocates D2 mentions std.algorithm
 as one of its main strengths, and never as a liability. I have
 difficulty reconciling that signal with one opinion relayed anonymously.


 I think the main problem is with ddoc. This, from std.algorithm is a
 f**king mess IMO:

 Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference
 SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter
 SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront
 canFind completeSort copy count endsWith equal fill filter find
 findAdjacent findAmong group indexOf initializeAll insert isPartitioned
 isSorted largestPartialIntersection largestPartialIntersectionWeighted
 levenshteinDistance levenshteinDistanceAndPath makeIndex map max min
 minCount minPos mismatch move moveAll moveSome nWayUnion no none
 partialSort partition reduce remove reverse schwartzSort semistable
 setDifference setIntersection setSymmetricDifference setUnion skipOver
 sort splitter stable startsWith substitute swap swapRanges topN topNCopy
 uninitializedFill uniq unstable until yes

 (in voice of comic-book guy) Worst navigation bar ever.

 -Steve


Let's fix it! I'm thinking along the lines of finding some broad groups, 
e.g.

Searching

find until mismatch startsWith ...

Sorting

sort partialSort partition ...

Set operations

setUnion setDifference ...

...?

We'd eliminate the unstructured "jump to" section and we create the 
grouping by hand (sigh).


Andrei
Jan 31 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Andrei Alexandrescu wrote:

 We'd eliminate the unstructured "jump to" section and we create the
 grouping by hand (sigh).


Maybe we can get the best of both worlds: how about a "Group:" or
"Tags:" section in the ddoc that a program could automatically
pull out to make the listing?

I think we can do that without modifying the compiler. Scanning
the text in javascript or whatever for that section would be simple
enough.
Jan 31 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/31/11 1:22 PM, Adam Ruppe wrote:

 Andrei Alexandrescu wrote:

 We'd eliminate the unstructured "jump to" section and we create the
 grouping by hand (sigh).


 Maybe we can get the best of both worlds: how about a "Group:" or
 "Tags:" section in the ddoc that a program could automatically
 pull out to make the listing?

 I think we can do that without modifying the compiler. Scanning
 the text in javascript or whatever for that section would be simple
 enough.


Great idea!

Andrei
Jan 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 31, 2011 11:13:40 Andrei Alexandrescu wrote:

 On 1/31/11 1:07 PM, Steven Schveighoffer wrote:

 On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:

 On 01/31/2011 01:18 AM, foobar wrote:

 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.


 
 From what I've seen, everyone who advocates D2 mentions std.algorithm
 as one of its main strengths, and never as a liability. I have
 difficulty reconciling that signal with one opinion relayed anonymously.


 
 I think the main problem is with ddoc. This, from std.algorithm is a
 f**king mess IMO:
 
 Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference
 SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter
 SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront
 canFind completeSort copy count endsWith equal fill filter find
 findAdjacent findAmong group indexOf initializeAll insert isPartitioned
 isSorted largestPartialIntersection largestPartialIntersectionWeighted
 levenshteinDistance levenshteinDistanceAndPath makeIndex map max min
 minCount minPos mismatch move moveAll moveSome nWayUnion no none
 partialSort partition reduce remove reverse schwartzSort semistable
 setDifference setIntersection setSymmetricDifference setUnion skipOver
 sort splitter stable startsWith substitute swap swapRanges topN topNCopy
 uninitializedFill uniq unstable until yes
 
 (in voice of comic-book guy) Worst navigation bar ever.
 
 -Steve


 
 Let's fix it! I'm thinking along the lines of finding some broad groups,
 e.g.
 
 Searching
 
 find until mismatch startsWith ...
 
 Sorting
 
 sort partialSort partition ...
 
 Set operations
 
 setUnion setDifference ...
 
 ...?
 
 We'd eliminate the unstructured "jump to" section and we create the
 grouping by hand (sigh).


At minimum, it needs to be smarter about user-defined types. The functions for
a 
class or struct should not be grouped with free functions. They should be 
grouped with the type that they're in. _That_, at least, should be automatable, 
but it wouldn't help any with std.algorithm, since it's full of free functions 
(though it would be a big improvement for std.datetime). Unfortunately, you 
can't really automate the sorting based on usage. Best case, you could create 
tags on functions that said which grouping they went in, and perhaps that would 
be well worth doing, but you still have to worry about tagging them. So, on
some 
level, the grouping is going to have to be done by hand.

- Jonathan M Davis
Jan 31 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-31 14:13:40 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Let's fix it! I'm thinking along the lines of finding some broad groups, e.g.
 
 Searching
 
 find until mismatch startsWith ...
 
 Sorting
 
 sort partialSort partition ...
 
 Set operations
 
 setUnion setDifference ...
 
 ...?
 
 We'd eliminate the unstructured "jump to" section and we create the 
 grouping by hand (sigh).


Please do. Grouping by task is very useful when you're searching for a 
particular function.

That said, it'd help if Ddoc could help too... For documenting 
Objective-C files I have made my own documentation generator (written 
in D!) which gives you this kind of output:
<http://michelf.com/projects/asounding/reference/class-ASNEngine.html>

For generating the above page, all I have to do in my header file is to 
specify which documentation group each function belongs to and the rest 
is done automatically. Here's the corresponding header file; notice I 
only have to write a  group directive when the group changes, not for 
each function:
<http://michelf.com/docs/tests/ASNEngine.h>



-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 31 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/31/2011 08:32 PM, Jonathan M Davis wrote:

 At minimum, it needs to be smarter about user-defined types. The functions for
a
 class or struct should not be grouped with free functions. They should be
 grouped with the type that they're in._That_, at least, should be automatable,


Isn't that's what namespaces are for? A big advantage of OO-like coding (or 
custom namespaces) for std modules.


 but it wouldn't help any with std.algorithm, since it's full of free functions
 (though it would be a big improvement for std.datetime).


See above. Why aren't many algorithms implemented in the modules defining what 
they operate on? Sure, "free" algorithms precisely are meant ot be generic. But 
in most cases there is, or could (should) be, a top-level type. In particular, 
don't many algos work on ranges?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Steven Schveighoffer wrote:

 I think the main problem is with ddoc.  This, from std.algorithm is a
 f**king mess IMO:


Note that that is generated through some short javascript in the
html header.

I remember writing a brief change to that to make it look a lot
better (organized into a simple grid) but it seems to be lost now.

I'd be willing to redo it though. Need to make a github account
to get commit power back, but if there's agreement on changes, I'll
make them.
Jan 31 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 14:17:50 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:


 Steven Schveighoffer wrote:

 I think the main problem is with ddoc.  This, from std.algorithm is a
 f**king mess IMO:


 Note that that is generated through some short javascript in the
 html header.

 I remember writing a brief change to that to make it look a lot
 better (organized into a simple grid) but it seems to be lost now.

 I'd be willing to redo it though. Need to make a github account
 to get commit power back, but if there's agreement on changes, I'll
 make them.


I'm all for it (voice with no authority).

I typically ignore that Jump To bar and use the browser's find.

I really think ddoc needs to be revamped to do more in this area, along  
with cross-linking.  I really like dil's output (see tangos' docs).

-Steve
Jan 31 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Steven Schveighoffer wrote:

 I'm all for it (voice with no authority).


Here it is with the brief css change to put it in a grid:

http://arsdnet.net/d-web-site/std_algorithm.html

It's a very small change that, to me, makes a huge difference.


 I really think ddoc needs to be revamped to do more in this area,
 along with cross-linking.


Agreed. Though, if we can't change the compiler, we could do this
with a macro too.

Use ($func std.file.read) to read a file.

And the $func macro can simply link it to the right place, or to
something like my own dpldocs.info/std.file.read to redirect/search
for the referenced item.

Say... I wonder... there's already a class "d_psymbol" in the
html, I could do this in the script too, or maybe with a simple
tweak to the existing macro.

I did it in script on that same link. I'm not in love with it,
but it proves the concept is easy enough with what we already
have.
Jan 31 2011
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
 Say... I wonder... there's already a class "d_psymbol" in the


No, I'm wrong. That's only the currently referenced symbol. No
point linking back to itself!

Gotta go back to the drawing board for good cross referencing.
Jan 31 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:


 Steven Schveighoffer wrote:

 I'm all for it (voice with no authority).


 Here it is with the brief css change to put it in a grid:

 http://arsdnet.net/d-web-site/std_algorithm.html

 It's a very small change that, to me, makes a huge difference.


It does help, but I was kind of hoping for something that shows the  
structure.  For example I see 'OpenRight' is an enum, and 'yes' is a  
member of that enum, but they are listed in random order (OpenRight coming  
at the beginning and yes coming at the end).  This is still pretty much  
fail.


 I really think ddoc needs to be revamped to do more in this area,
 along with cross-linking.


 Agreed. Though, if we can't change the compiler, we could do this
 with a macro too.


I think the compiler needs to change.  See dil for an example of how much  
better it could be. http://dl.dropbox.com/u/17101773/doc/dil/main.html

Also I think before descent was abandoned, it added cross-linking, but I'm  
not sure what state that is in (or if it went over to DDT).

-Steve
Jan 31 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 31.01.2011 22:06, schrieb Steven Schveighoffer:

 On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe <destructionator gmail.com>
wrote:
 

 Steven Schveighoffer wrote:

 I'm all for it (voice with no authority).


 Here it is with the brief css change to put it in a grid:

 http://arsdnet.net/d-web-site/std_algorithm.html

 It's a very small change that, to me, makes a huge difference.


 
 It does help, but I was kind of hoping for something that shows the structure. 
 For example I see 'OpenRight' is an enum, and 'yes' is a member of that enum,
 but they are listed in random order (OpenRight coming at the beginning and yes
 coming at the end).  This is still pretty much fail.
 


For D1 (maybe it works with D2 as well? It used dmd) there was CandyDoc
(I think the latest version was in the dsss svn?)
It produced a good overview, IMHO, see http://bildupload.sro.at/p/370054.html
Jan 31 2011
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Steven Schveighoffer wrote:

 It does help, but I was kind of hoping for something that shows the
 structure.


Those relationships are in the HTML too.... try it now:
http://arsdnet.net/d-web-site/std_algorithm.html

(I know it needs some work still, I'm just sick of Javascript after
spending 20 minutes tracking down a bug caused by me using the
same variable name twice! Gah! And wow do I miss foreach.)
Jan 31 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:


 (I know it needs some work still, I'm just sick of Javascript after
 spending 20 minutes tracking down a bug caused by me using the
 same variable name twice! Gah! And wow do I miss foreach.)


A good C lint is very good at spotting that kind of bugs. There are lints for
JS too, but I don't know if they are able to spot this kind of bug.

Bye,
bearophile
Jan 31 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 18:08:53 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:


 Steven Schveighoffer wrote:

 It does help, but I was kind of hoping for something that shows the
 structure.


 Those relationships are in the HTML too.... try it now:
 http://arsdnet.net/d-web-site/std_algorithm.html

 (I know it needs some work still, I'm just sick of Javascript after
 spending 20 minutes tracking down a bug caused by me using the
 same variable name twice! Gah! And wow do I miss foreach.)


Yes, it's in the right direction, but it does need work.

BTW, foreach is available, but you can't use it on arrays (HAHAHAHA!)

it's one of the reasons I use objects in JS most of the time instead of  
arrays:

for(key in obj)
{
    var elem = obj[key];
    /* use elem */
}

of course, I'd only recommend this on objects you have used as arrays.   
What I mean by that is, you don't have any methods or prototypes, because  
those will also be iterated.

https://developer.mozilla.org/en/JavaScript/Reference/Statements/for...in

-Steve
Feb 01 2011
prev sibling parent reply foobar <foo bar.com> writes:
Walter Bright Wrote:


 foobar wrote:

 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which

 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.


 
 I think you've mixed up libraries with languages. Please rephrase so we know 
 what you're referring to and give specifics.
 


I just tried to save typing :) 
Just replace above "language foo" with "language foo's standard library" 

Java (the language itself) is mediocre at best but the Java standard libraries
are excellent with comprehensive usable documentation to boot. 

Phobes is half a notch above c++ stdlib which is the worst ever from a
usability and readability perspective. Are we still using G-d files? really?
Jan 30 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
foobar wrote:

 Java (the language itself) is mediocre at best but the Java standard
 libraries are excellent with comprehensive usable documentation to boot.
 
 Phobes is half a notch above c++ stdlib which is the worst ever from a
 usability and readability perspective. Are we still using G-d files? really?


Please take a module or function in the phobos documentation, and rewrite it to 
how you think it should be done and post it, as an example of how to do it 
right. We welcome such help.
Jan 30 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 10:18 PM, foobar wrote:

 Right, so does that mean it should be made_less_  readable by a diverse
community of people?
 I have no issue with any style Andrei or others use when they code for
themselves, be it 10 characters per row or 1000.
 I do place a MUCH higher weight on making the stdlib readable and accessible
for a large range of diverse people with different cultures, languages,
traditions, eye-sight, screen sizes, and preferred beer flavors.


There is only one true beer flavor.


 ATM, Phobos ranks extremely poorly in this regard.


Sure. How can we ensure Phobos contributors drink Pilsner Urquell? 
http://en.wikipedia.org/wiki/Pilsner_Urquell

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
foobar wrote:

 Tomek Sowi=C5=84ski Wrote:
=20

 Andrej Mitrovic napisa=C5=82:


 If you really want to set up a column limit that *everyone* has to ab=






ide 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 tha=




t 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)

 --=20
 Tomek


=20
 I think that putting an artificial limit is incredibly stupid. Haven't =


anyone here learned the "No magic numbers" rule?!?!

=20
 Walter correctly pointed out that it's harder to read long rows, howeve=


r, unlike printed text and ancient terminals, current display technology =
is much more dynamic.=20

 Font size, zoom level, screen form-factor, window size, resolution, etc=


 means that each person can configure his own individual optimal view.=20

=20
 As the OP said, use word wrap and adjust your editor window width/font =


size/zoom level/etc to your liking.=20

 If your editor does not support this "new" feature, go get a new editor=


 and don't bother other people with different preferences.

 Stop forcing this moronic "one size fits all" attitude on everyone.=20


	Do you know of any editor that can word wrap *while respecting
indentation*? Any editor I know will wrap to the first column, which
renders indentation pointless in the presence of long lines...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 30 2011
next sibling parent foobar <foo bar.com> writes:
Jérôme M. Berger Wrote:


 foobar wrote:

 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)

 -- 
 Tomek


 
 I think that putting an artificial limit is incredibly stupid. Haven't anyone
here learned the "No magic numbers" rule?!?!
 
 Walter correctly pointed out that it's harder to read long rows, however,
unlike printed text and ancient terminals, current display technology is much
more dynamic. 
 Font size, zoom level, screen form-factor, window size, resolution, etc means
that each person can configure his own individual optimal view. 
 
 As the OP said, use word wrap and adjust your editor window width/font
size/zoom level/etc to your liking. 
 If your editor does not support this "new" feature, go get a new editor and
don't bother other people with different preferences.
 Stop forcing this moronic "one size fits all" attitude on everyone. 


 
 	Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...
 
 		Jerome
 -- 
 mailto:jeberger free.fr
 http://jeberger.free.fr
 Jabber: jeberger jabber.fr
 
 


I personally prefer long lines and always code (in eclipse) when the code
editor is maximized. I never needed to word-wrap code due to my preferences but
every time I need to edit code written by a co-worker that uses Emacs on only a
third of the screen I struggle with the many redundant line breaks that just
keep breaking my train of thought. 
I'm sure that it's trivial to add to a code editor that already provides auto
indentation a mode to do the same for word-wrap if it doesn't do that yet. In
any case, Even without that, it's much more readable than forcing redundant
line breaks in the middle of code-lines (e.g. "sentences").
Jan 30 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-30 15:32:45 -0500, "Jérôme M. Berger" <jeberger free.fr> said:


 	Do you know of any editor that can word wrap *while respecting
 indentation*?


Xcode.

Wrapped line are indented 2 spaces more than the true indent of the 
line. Given that indentation is generally done by a factor of 4 spaces, 
it's really easy to spot a wrapped line. This is configurable, of 
course.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 30 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Michel Fortin wrote:

 On 2011-01-30 15:32:45 -0500, "J=C3=A9r=C3=B4me M. Berger" <jeberger fr=


ee.fr> said:

=20

     Do you know of any editor that can word wrap *while respecting
 indentation*?


=20
 Xcode.
=20
 Wrapped line are indented 2 spaces more than the true indent of the
 line. Given that indentation is generally done by a factor of 4 spaces,=



 it's really easy to spot a wrapped line. This is configurable, of cours=


e.

=20


	So that makes one very platform-specific editor.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 31 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jérôme M. Berger wrote:

 	Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...


Word-wrapping code is a bad idea.
Jan 30 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Walter Bright wrote:

 J=C3=A9r=C3=B4me M. Berger wrote:

     Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...


=20
 Word-wrapping code is a bad idea.


	My point exactly.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 31 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 01/30/2011 09:32 PM, "Jérôme M. Berger" wrote:

 foobar wrote:

 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)

 --
 Tomek


 I think that putting an artificial limit is incredibly stupid. Haven't anyone
here learned the "No magic numbers" rule?!?!

 Walter correctly pointed out that it's harder to read long rows, however,
unlike printed text and ancient terminals, current display technology is much
more dynamic.
 Font size, zoom level, screen form-factor, window size, resolution, etc means
that each person can configure his own individual optimal view.

 As the OP said, use word wrap and adjust your editor window width/font
size/zoom level/etc to your liking.
 If your editor does not support this "new" feature, go get a new editor and
don't bother other people with different preferences.
 Stop forcing this moronic "one size fits all" attitude on everyone.


 	Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...

 		Jerome


Yop, geany :-) http://en.wikipedia.org/wiki/Geany

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
spir wrote:

 On 01/30/2011 09:32 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:

     Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...

         Jerome


=20
 Yop, geany :-) http://en.wikipedia.org/wiki/Geany
=20


	Nope it wraps to the same indent level as the original line, so you
do not see at a glance that a line is wrapped.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 31 2011
parent spir <denis.spir gmail.com> writes:
On 01/31/2011 11:33 PM, "Jérôme M. Berger" wrote:

 	Nope it wraps to the same indent level as the original line, so you
 do not see at a glance that a line is wrapped.


It shows it's a wrapped line using a dedicated "wrapping-arrow" sign. I never 
use this feature for code, though.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/31 spir <denis.spir gmail.com>:

 On 01/30/2011 09:32 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:

 =C2=A0 =C2=A0 =C2=A0 =C2=A0Do you know of any editor that can word wrap =




*while respecting

 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...


 Yop, geany :-) http://en.wikipedia.org/wiki/Geany


Kate does this too, and clearly marks out it's an auto-wrapped line
http://imagebin.org/135452

Personally, I'd like it to find the starting-parenthesis of the call
and indent to it, though.
Jan 31 2011
prev sibling next sibling parent David Nadlinger <see klickverbot.at> writes:
On 1/30/11 7:55 PM, 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)


80
Jan 30 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 30.01.2011 19:55, schrieb Tomek Sowiński:

 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)


about 100 (don't care if its 2 chars more to fit a ");" or something 
like that)
Jan 30 2011
prev sibling next sibling parent Jim <bitcirkel yahoo.com> writes:
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)
 
 -- 
 Tomek
 



--- No limit ---

Although indentation makes lines "longer" they do not make them harder to read.
So I don't put an artificial limit because I don't know how many levels of
indentation I will need.

Do you manually adjust and put new line-breaks on every line of code if you
need to add a level on indentation???
Jan 30 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Tomek Sowinski" <just ask.me> wrote in message 
news:20110130195553.5db1ed2e Las-Miodowy...

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


I generally try to stick to about 80 as a rule-of-thumb, but I'll go up to 
around 100 (or more in rare cases, but in those cases I cringe) when I think 
breaking it would uglify it too much. So I don't really have an exact 
number.
Jan 30 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 30 January 2011 10:55:53 Tomek Sowi=C5=84ski wrote:

 Andrej Mitrovic napisa=C5=82:

 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.


=20
 Actually that's a splendid idea. Let's take it easy. Regardless of that
 silly beef I'm really curious what distribution will emerge.
=20
 What is your preferred *maximum* length for a line of D code? (please rep=


ly

 with a number only)


My _preferred_ limit would be no limit but that if your line is getting to =
be=20
around 100 - 120 characters, then you should really look at breaking it up.=
 If I=20
had to have a hard limit, I'd then pick 120 so that it would be rare that I=
'd=20
have to worry about it, and if I had to compromise a bit because others tho=
ught=20
that that was too long, then I'd pick 100. Particularly when you get much=20
indentation going on and _especially_ when you have descriptive names, it's=
=20
pretty easy to hit 80 characters, and it definitely feels overly limiting.=
=20
Personally, I find that it harms code formatting readability to consistentl=
y be=20
forced to break up lines due to an 80 character limit. It's especially bad =
when=20
you treat it as an absolute, hard limit, and things like the semicolon at t=
he=20
end of the line make it so that you hit 81 characters and have to break up =
the=20
line.

So, if I have any say on the matter, I'd say 100 - 120 characters max if we=
're=20
putting a limit on it. I do feel very strongly about coding style, because =
I=20
hate having to twist how I write code to fit another style (though fortunat=
ely,=20
my natural style is at least close to how Phobos generally is). However, it=
 is=20
normal to have to adjust your coding style on some level when working in a=
=20
group. I don't want to make a big stink about it either. 80 characters per =
line=20
_is_ one of the worst conventions out there IHMO, but if that's what we go =
with,=20
then I'll do it.

I suspect that the major reason that many of my lines tend to go over 80=20
characters is that I almost always pick very descriptive variable and funct=
ion=20
names, and that makes lines longer. It could be that if a programmer who fa=
vored=20
short variable names were to write the same code that I typically do, then=
=20
they'd almost always stay within 80 characters.

In any case, I vote 100 - 120 characters for the limit, and I'd _really_ li=
ke to=20
not be restricted to 80 characters, but if that's what I have to do, then t=
hat's=20
what I have to do.

=2D Jonathan M Davis
Jan 30 2011
prev sibling next sibling parent Don <nospam nospam.com> writes:
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.
Jan 31 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
90 as a rule of thumb with some exceptions.
Jan 31 2011
prev sibling next sibling parent reply foobar <foo bar.com> writes:
Walter Bright Wrote:


 foobar wrote:

 Java (the language itself) is mediocre at best but the Java standard
 libraries are excellent with comprehensive usable documentation to boot.
 
 Phobes is half a notch above c++ stdlib which is the worst ever from a
 usability and readability perspective. Are we still using G-d files? really?


 
 Please take a module or function in the phobos documentation, and rewrite it
to 
 how you think it should be done and post it, as an example of how to do it 
 right. We welcome such help.


My complaint is not about the implementation itself as it is about it's API. 
Java is an excellent example of many very usable APIs, meaning that it very
easy to both read Java code and understand what the functions do and write code
that's just as readable *without* RTFM. 

When I learned C++ in university, my notoriously demanding professor said that
code should be self documenting and that comments are meant to compensate for
poorly written code.
Jan 31 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
foobar wrote:

 Walter Bright Wrote:
 

 foobar wrote:

 Java (the language itself) is mediocre at best but the Java standard 
 libraries are excellent with comprehensive usable documentation to boot.
 
 Phobes is half a notch above c++ stdlib which is the worst ever from a 
 usability and readability perspective. Are we still using G-d files?
 really?


 Please take a module or function in the phobos documentation, and rewrite
 it to how you think it should be done and post it, as an example of how to
 do it right. We welcome such help.


 
 My complaint is not about the implementation itself as it is about it's API.
  Java is an excellent example of many very usable APIs, meaning that it very
 easy to both read Java code and understand what the functions do and write
 code that's just as readable *without* RTFM.



Please take a Phobos module or a function, and rewrite its API to demonstrate 
your point.
Jan 31 2011
prev sibling parent so <so so.do> writes:
 Java is an excellent example of many very usable APIs, meaning that it  
 very easy to both read Java code and understand what the functions do  
 and write code that's just as readable *without* RTFM.


This one i don't understand. (seems i fail to understand many things  
nowadays!).
I have read the C++ standard library manuals many times, but still i find  
myself going back and reading it again occasionally.
Probably like my memory, STL also doesn't have the best of qualities.
But i have to ask, why would you target those that don't RTFM? It seems to  
me every language mainly targeting this kind of audience.
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jan 2011 13:55:53 -0500, Tomek Sowiński <just ask.me> 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)


80

-Steve
Jan 31 2011
prev sibling next sibling parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Tomek Sowi=C5=84ski napisa=C5=82:


 Actually that's a splendid idea. Let's take it easy. Regardless of that s=


illy beef I'm really curious what distribution will emerge.

=20
 What is your preferred *maximum* length for a line of D code? (please rep=


ly with a number only)
=20
Alright, I'm wrapping up this toy study. Two things before the numbers come:

 - A few respondents gave 2 numbers, one "reasonable", the other "if I real=
ly have to". I took the latter (larger) number as I was after maximum lengt=
h, something usable as a setting for a repository hook.
 - 2 respondents said "no limit". I excluded them from computations, albeit=
 it's a valid answer. 1 respondent answered "1 mole" which I also excluded =
as a 22-order-of-magnitude outlier.


 lengths =3D c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90)
 summary(lengths)


   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.=20
  80.00   80.00  100.00   97.27  110.00  120.00=20




[1] 16.18080

 quantile(lengths, c(.1, .25, .5, .75, .9))


10% 25% 50% 75% 90%=20
 80  80 100 110 120=20

 library(moments)



[1] 0.1645005




[1] 11

--=20
Tomek
Jan 31 2011
next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Tomek Sowi=C5=84ski napisa=C5=82:


 Alright, I'm wrapping up this toy study. Two things before the numbers co=


me:

=20
  - A few respondents gave 2 numbers, one "reasonable", the other "if I re=


ally have to". I took the latter (larger) number as I was after maximum len=
gth, something usable as a setting for a repository hook.

  - 2 respondents said "no limit". I excluded them from computations, albe=


it it's a valid answer. 1 respondent answered "1 mole" which I also exclude=
d as a 22-order-of-magnitude outlier.

Steven came in late with his datapoint, so once again:


 lengths =3D c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90, 80)
=20
 summary(lengths)


   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.=20
  80.00   80.00   95.00   95.83  110.00  120.00=20

=20



[1] 16.21354

=20
 quantile(lengths, c(.1, .25, .5, .75, .9))


10% 25% 50% 75% 90%=20
 80  80  95 110 119=20

=20



[1] 0.3121957

=20



[1] 12

--=20
Tomek
Jan 31 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Tomek Sowiński wrote:

 1 respondent answered "1 mole" which I also excluded as a 22-order-of-magnitude
 outlier.


What kind of a jerk is that respondent?
Jan 31 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 07:55 PM, 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)


99

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:


 On 1/31/11 1:07 PM, Steven Schveighoffer wrote:

 On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 01/31/2011 01:18 AM, foobar wrote:



 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.


 From what I've seen, everyone who advocates D2 mentions std.algorithm
 as one of its main strengths, and never as a liability. I have
 difficulty reconciling that signal with one opinion relayed anonymously.


 I think the main problem is with ddoc. This, from std.algorithm is a
 f**king mess IMO:

 Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference
 SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter
 SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront
 canFind completeSort copy count endsWith equal fill filter find
 findAdjacent findAmong group indexOf initializeAll insert isPartitioned
 isSorted largestPartialIntersection largestPartialIntersectionWeighted
 levenshteinDistance levenshteinDistanceAndPath makeIndex map max min
 minCount minPos mismatch move moveAll moveSome nWayUnion no none
 partialSort partition reduce remove reverse schwartzSort semistable
 setDifference setIntersection setSymmetricDifference setUnion skipOver
 sort splitter stable startsWith substitute swap swapRanges topN topNCopy
 uninitializedFill uniq unstable until yes

 (in voice of comic-book guy) Worst navigation bar ever.

 -Steve


 
 Let's fix it! I'm thinking along the lines of finding some broad groups, 
 e.g.
 
 Searching
 
 find until mismatch startsWith ...
 
 Sorting
 
 sort partialSort partition ...
 
 Set operations
 
 setUnion setDifference ...
 
 ...?


Excellent!


 
 We'd eliminate the unstructured "jump to" section and we create the 
 grouping by hand (sigh).
 


You just got my hopes up in the previous paragraph..... :(

How about converting algorithm.d into a package and make those "groups" modules
in this package? 
I'm sure this can be done with the help of some aliases for backwards
compatibility


 
 Andrei
Jan 31 2011
prev sibling next sibling parent foobar <foo bar.com> writes:
Adam Ruppe Wrote:


 Steven Schveighoffer wrote:

 It does help, but I was kind of hoping for something that shows the
 structure.


 
 Those relationships are in the HTML too.... try it now:
 http://arsdnet.net/d-web-site/std_algorithm.html
 
 (I know it needs some work still, I'm just sick of Javascript after
 spending 20 minutes tracking down a bug caused by me using the
 same variable name twice! Gah! And wow do I miss foreach.)


var foo = [bar, baz];
foo.forEach(function (elem) { 
    elem.doSomthing(); 
});

Available since version 1.6
Feb 01 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Feb 10 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:ii46g5$1g66$1 digitalmars.com...

 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.


Heh :)

This is what I do: My editor shows a faint vertical line at the end of 
column 80. I use that as a rough general guideline, but not a hard-and-fast 
rule.

I agree with Andrei that the longer a line of code or text gets beyond 80 
columns, the harder it gets to read. Heck, I had one co-worker once who had 
his code total-fullscreen on a 16:9 with lines extending all the way to the 
end: it was horrible. I do think you can go a little bit further than 80 
columns while still being perfectly readable, but I think 80 is a sensible 
time-honered rule of thumb for maximum compatibility as long as you're not 
too strict about it.

One other reason to not be too strict about the 80-column guideline is 
elastic tabstops. With those, propotional fonts become perfectly sensible to 
use for code, and then "80-columns" inherently becomes "fuzzy".

Minor side note: Vertical space being much more important than horizontal 
for both code and other text is the primary reason I'd never consider 
getting a widescreen monitor. (For TV's I can go either way, though, as long 
as the non-widescreen can properly scale/letterbox widescreen signals.)



 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.


Like Andrei said, it may not be a technical limitation anymore, but it is 
still a human limitation. Any remotely modern computer is perfectly capable 
of speeding up voice playback by 10x, but nobody does it that fast because 
the human user is the limiting factor.

Of course, if someone said "let's use 90 or 100 lines as the guideline", I 
wouldn't object at all. But 80 has a lot of history behind it, and is 
therefore much easier to agree on as a rough standard, and it does still 
work out, again, as long as you're not too strict about it. (And it doesn't 
hurt that I'm a fan of both powers-of-two and the 1980's, so there's that 
nice warm psychological connection ;) )



 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?


There's a lot of text-mode junkies out there. And for Unix users, there may 
be times when they need to work in pure text-mode. Also, it's common to have 
a million other frames showing (see a typical Eclipse setup), so that can 
really limit how many columns people have available, too.



 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. :)


He probably already has as many as his cubicle will hold ;)



 2. A widescreen aspect ratio causes less eye strain. Wider code means the 
 same.


That's just plain rediculous. I don't know where you got that. *Maybe* for 
watching video, but certainly not text.



 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.


FWIW, I'd write that this way:

void main()
{
    void foo()
    {
       while(true)
       if(done)
       {
       }
    }
}

I'm a big fan of "stacking" flow-control statements like that whenever the 
outer statements don't have anything else in their body.

Like this (stupid example):

// Draw funny design (and yes, this could be optimized better)
if(shouldRefresh)
foreach(int x; 0..width)
foreach(int y; 0..height)
if(x ^ y < width*height / 2)
    buffer[x + y*width] = palette[(x+y) % $];

Instead of something more like:

// Draw funny design (and yes, this could be optimized better)
if(shouldRefresh)
{
    foreach(int x; 0..width)
    {
        foreach(int y; 0..height)
        {
            if(x ^ y < width*height / 2)
                buffer[x + y*width] = palette[(x+y) % $];
        }
    }
}


 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.


That's not a bad point. But if a line is that long, it's going to be 
difficult to read anyway without doing it manually and taking syntax into 
acount:

auto str = join(formatStr1, formatStr2, formatStr3, formatStr4,
    formatStr5).format(someValue1, someValue2, cond? ""
    : someStr, someValue3 + someValue4);

Vs:

auto str =
    join(
        formatStr1, formatStr2, formatStr3,
        formatStr4, formatStr5 )
    .format(
        someValue1,
        someValue2,
        cond? "" : someStr,
        someValue3 + someValue4 );

I find the second one perfectly readable, but I can't even make head or 
tails of the first one, and I just wrote it a few seconds ago!



 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.


I'm rarely editing only one file at a time. Frequently a whole handful. (But 
I "Ctrl-Tab" through them.)



 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.


Sounds fair. (But I'm not a Phobos dev, so my opinion on that is probably 
irrelevent.)
Jan 30 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 80 colums is an artifact of the old age.




An elegant width, from a more civilized age.


 Any remotely modern computer is perfectly capable
 of speeding up voice playback by 10x, but nobody does it that fast because
 the human user is the limiting factor.


People who use screen readers often crank up the playback rate to 2x. The 
software adjusts the pitch so it doesn't sound like the Chipmunks.

I've often wondered why DVRs don't do this (I've sent the suggestion to Tivo, 
they ignored me). I'd like the option to play the news (or other talk shows) at 
a faster rate, with pitch adjustment. I've found I can watch Tivo at 3x with
the 
closed captioning on, and can almost keep up. The problem with DVRs at any fast 
forward speed is they turn the sound off! Grrrr.

A golden opportunity missed.

I'd also love it if youtube etc. did this. It's so boring looking at youtube 
presentations because they talk so slow. I'd love a double speed youtube
viewing 
option.

Remember I posted this in case some troll tries to patent it.
Jan 30 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Remember I posted this in case some troll tries to patent it.


I sometimes see&hear documentaries at 140-160% speed.

Bye,
bearophile
Jan 30 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ii4p8u$2ico$1 digitalmars.com...

 Nick Sabalausky wrote:

 80 colums is an artifact of the old age.




 An elegant width, from a more civilized age.


 Any remotely modern computer is perfectly capable
 of speeding up voice playback by 10x, but nobody does it that fast 
 because
 the human user is the limiting factor.


 People who use screen readers often crank up the playback rate to 2x. The 
 software adjusts the pitch so it doesn't sound like the Chipmunks.

 I've often wondered why DVRs don't do this (I've sent the suggestion to 
 Tivo, they ignored me). I'd like the option to play the news (or other 
 talk shows) at a faster rate, with pitch adjustment. I've found I can 
 watch Tivo at 3x with the closed captioning on, and can almost keep up. 
 The problem with DVRs at any fast forward speed is they turn the sound 
 off! Grrrr.

 A golden opportunity missed.

 I'd also love it if youtube etc. did this. It's so boring looking at 
 youtube presentations because they talk so slow. I'd love a double speed 
 youtube viewing option.

 Remember I posted this in case some troll tries to patent it.


I wish someone would finally just patent getting patents. (IBM's come close 
from what I hear, but it's not quite there yet.) That's probably the only 
way the US will ever be rid of the dammed things. Heck, with the USPTO being 
as grossly incompetent as it is, it would probably be granted: it would just 
have to be written in a sufficiently ultra-pedantic style.
Jan 30 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 I wish someone would finally just patent getting patents. (IBM's come close 
 from what I hear, but it's not quite there yet.) That's probably the only 
 way the US will ever be rid of the dammed things. Heck, with the USPTO being 
 as grossly incompetent as it is, it would probably be granted: it would just 
 have to be written in a sufficiently ultra-pedantic style.



I agree that patents are a blight on the industry.
Jan 30 2011
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 01/30/2011 04:29 PM, Nick Sabalausky wrote:

 Minor side note: Vertical space being much more important than horizontal
 for both code and other text is the primary reason I'd never consider
 getting a widescreen monitor.


Widescreen monitors are awesome as an alternative to dual-screen 
monitors. I liked the idea of being able to compare stuff side-by-side 
with dual screens, but never liked the implementation. Too much fussing 
around and an ugly gap in the middle.

As for vertical space, I just made sure the monitor I bought had as much 
or more than the old one it replaced.
Jan 30 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jeff Nowakowski" <jeff dilacero.org> wrote in message 
news:ii4rdu$2lvc$1 digitalmars.com...

 On 01/30/2011 04:29 PM, Nick Sabalausky wrote:

 Minor side note: Vertical space being much more important than horizontal
 for both code and other text is the primary reason I'd never consider
 getting a widescreen monitor.


 Widescreen monitors are awesome as an alternative to dual-screen monitors. 
 I liked the idea of being able to compare stuff side-by-side with dual 
 screens, but never liked the implementation. Too much fussing around and 
 an ugly gap in the middle.


Yea, not bad at that.


 As for vertical space, I just made sure the monitor I bought had as much 
 or more than the old one it replaced.


I'm typically limited more horizontally than vertically, so replacing a 
non-widescreen with a widescreen that's at least as tall would likely mean 
getting one that's too wide to fit.
Jan 30 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 10:29 PM, Nick Sabalausky wrote:

 void main()
 {
      void foo()
      {
         while(true)
         if(done)
         {
         }
      }
 }

 I'm a big fan of "stacking" flow-control statements like that whenever the
 outer statements don't have anything else in their body.

 Like this (stupid example):

 // Draw funny design (and yes, this could be optimized better)
 if(shouldRefresh)
 foreach(int x; 0..width)
 foreach(int y; 0..height)
 if(x ^ y<  width*height / 2)
      buffer[x + y*width] = palette[(x+y) % $];

 Instead of something more like:

 // Draw funny design (and yes, this could be optimized better)
 if(shouldRefresh)
 {
      foreach(int x; 0..width)
      {
          foreach(int y; 0..height)
          {
              if(x ^ y<  width*height / 2)
                  buffer[x + y*width] = palette[(x+y) % $];
          }
      }
 }


Nice idea :-) Really makes sense, imo.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 30/01/2011 17:17, Andrej Mitrovic wrote:
<snip>

 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.


Other than, as you begin to say, the difficulty in deciding on where to 
move the line to.


 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?


For all I know, people probably still do run the D compiler in the 
terminal app on Unix-like systems.


 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"*?


For all I know, Fortran programmers probably still do this kind of stuff 
all the time.  I guess the designers of Fortran 90 for some reason 
thought it was right to "protect" programmers by keeping a line length 
limit, though they did at least increase the limit to 132.  Does anyone 
here know how Fortran 95, 2003 and 2008 compare?

<snip>

 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.


But automatic word wrapping is usually designed to be used on prose, not 
program code.  Do those programs have a word wrapping algorithm that 
makes program code look good?

<snip>

 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.


<snip>

Therein lies the problem - in this day and age, everyone's screen is 
different, and everyone's needs are different.  Even if we can get 
people to agree on a limit of 100 in this day and age, it might not suit 
the programmers of the future.  After all, OUAT people managed with the 
32 columns of the ZX Spectrum.

Stewart.
Jan 30 2011
next sibling parent reply foobar <foo bar.com> writes:
Stewart Gordon Wrote:


 Therein lies the problem - in this day and age, everyone's screen is 
 different, and everyone's needs are different.  Even if we can get 
 people to agree on a limit of 100 in this day and age, it might not suit 
 the programmers of the future.  After all, OUAT people managed with the 
 32 columns of the ZX Spectrum.
 
 Stewart.


That's why I'm opposed to *any*  artificial limit as proposed by Andrei.
Jan 30 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/31/2011 01:48 AM, foobar wrote:

 Stewart Gordon Wrote:


 Therein lies the problem - in this day and age, everyone's screen is
 different, and everyone's needs are different.  Even if we can get
 people to agree on a limit of 100 in this day and age, it might not suit
 the programmers of the future.  After all, OUAT people managed with the
 32 columns of the ZX Spectrum.

 Stewart.


 That's why I'm opposed to *any*  artificial limit as proposed by Andrei.


Opposition rendered anonymously from an armchair quarterback has little 
credibility. If you join Phobos on technical merit, we will all be very 
glad to do our best to accommodate your needs.

Andrei
Jan 31 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 31.01.2011 00:17, schrieb Stewart Gordon:

 On 30/01/2011 17:17, Andrej Mitrovic wrote:
 <snip>

 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.


 Other than, as you begin to say, the difficulty in deciding on where to
 move the line to.


 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?


 For all I know, people probably still do run the D compiler in the
 terminal app on Unix-like systems.


1. The D-Compiler doesn't care if the code fits in your terminal
2. You can have bigger terminals than 80x25 - just resize your 
xterm/rxvt/gnome-terminal/putty/whatever
Jan 31 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ii67i0$1vf2$2 digitalmars.com...

 Am 31.01.2011 00:17, schrieb Stewart Gordon:

 For all I know, people probably still do run the D compiler in the
 terminal app on Unix-like systems.


 1. The D-Compiler doesn't care if the code fits in your terminal
 2. You can have bigger terminals than 80x25 - just resize your 
 xterm/rxvt/gnome-terminal/putty/whatever


Not if you're in text-mode. Which could happen if your X11 gets fucked. 
Which has happened to me [randomly] on more than one occasion. Of course, if 
that does happen, then editing D code probably wouldn't be your biggest 
priority, so I'm not really making much of a point here...
Jan 31 2011
prev sibling next sibling parent Max Samukha <maxsamukha spambox.com> writes:
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.


I think there is no need to establish a fixed limit. "Avoid long lines" 
recommendation in the style guide would be enough.
Jan 31 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 31, 2011 13:25:16 spir wrote:

 On 01/31/2011 08:32 PM, Jonathan M Davis wrote:

 At minimum, it needs to be smarter about user-defined types. The
 functions for a class or struct should not be grouped with free
 functions. They should be grouped with the type that they're in._That_,
 at least, should be automatable,


 
 Isn't that's what namespaces are for? A big advantage of OO-like coding (or
 custom namespaces) for std modules.
 

 but it wouldn't help any with std.algorithm, since it's full of free
 functions (though it would be a big improvement for std.datetime).


 
 See above. Why aren't many algorithms implemented in the modules defining
 what they operate on? Sure, "free" algorithms precisely are meant ot be
 generic. But in most cases there is, or could (should) be, a top-level
 type. In particular, don't many algos work on ranges?


Classes and structs already group functions naturally, and that grouping needs 
to be evident in the generated ddoc pages.

As for free functions, there's a huge difference between namespacing functions 
and grouping them in documentation. Namespacing was introduced in C++ to avoid 
name collisions. D uses modules as namespaces and also allows you to avoid name 
collisions. But that doesn't mean that there isn't value or necessity in 
grouping functions within a namespace or module. If there aren't all that many 
functions in a module, then you don't really need to group them, but when you 
get as many functions as you do in std.algorithm, it can definitely be useful. 
std.algorithm doesn't have problems with name collisions and doesn't need to be 
broken up, but it _is_ large enough that grouping some of its documentation 
would be useful. And simply grouping the links to the functions at the top
would 
be a definite improvement. Regardless, it's a separate issue from namespacing.

- Jonathan M Davis
Jan 31 2011