OCaml ExtLib

> Hi,
>
> since we are at it (syntax flamewars): I'd also propose keeping the
> horizontal limit of source lines to 80 characters...
>

Uh , this one is more problematic.
I agree that short lines are better but I dislike to break some code into
several expressions (or shorten identifier name or other tricks) only to
stick to that outdated 80 chars limit. I agree everyone is free to use its
own text editor - in 80 rows text mode or in 1600x1200 pixels graphics
mode - but when it turns into adding lines jumps into a nice expression only
because there is a damn paranthesis on the 81th row that's troublesome.
That's for my personal opinion.
Now, after having a quick look at some ExtLib sources, it appears that the
80chars limit is rarely overriden, so modifying some lines here and there
should not be so big thing if it keeps further people flames away :-)

Nicolas Cannasse

On Sun, 05 Oct 2003, Nicolas Cannasse wrote:
> I agree that short lines are better but I dislike to break some code into
> several expressions (or shorten identifier name or other tricks) only to
> stick to that outdated 80 chars limit.

It's outdated in the sense that our displays and printers can handle
better than this. The question is whether humans can. Enforcing this
(or another) limit keeps people from writing unreadable spaghetti code.
Unless you use extremely long identifiers, which should be discouraged
in any case, 80 chars should be more than enough.

> I agree everyone is free to use its
> own text editor - in 80 rows text mode or in 1600x1200 pixels graphics
> mode - but when it turns into adding lines jumps into a nice expression only
> because there is a damn paranthesis on the 81th row that's troublesome.

And if there is just one damn parenthesis on the 82nd row, or 83rd, or...

Get the drift? ;-)

> Now, after having a quick look at some ExtLib sources, it appears
> that the 80chars limit is rarely overriden, so modifying some lines
> here and there should not be so big thing if it keeps further people
> flames away :-)

You are absolutely right :-)

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@...

> On Sun, 05 Oct 2003, Nicolas Cannasse wrote:
> > I agree that short lines are better but I dislike to break some code
into
> > several expressions (or shorten identifier name or other tricks) only to
> > stick to that outdated 80 chars limit.
>
> It's outdated in the sense that our displays and printers can handle
> better than this. The question is whether humans can. Enforcing this
> (or another) limit keeps people from writing unreadable spaghetti code.
> Unless you use extremely long identifiers, which should be discouraged
> in any case, 80 chars should be more than enough.

Not a flame, but just some comments about that :
I just don't like such arbitrary rules made in the name of "protecting the
programmer from writing bad code". I mean, if a programmer is actually that
bad then he will write unreadable code no matter the chars limit :-)
Depending on the programming language, on the ident size and naming
conventions, and many others factors such as the programmer own style of
programming, this limit can vary a lot. Fixing it to 80 chars is nonsense.
Just let the programmer have his own judgement on the code readability he's
been writing.

Nicolas Cannasse

On Sun, 5 Oct 2003, Markus Mottl wrote:

> Hi,
> 
> since we are at it (syntax flamewars): I'd also propose keeping the
> horizontal limit of source lines to 80 characters...
> 

80 characters at what tab stop?  My code rarely breaks the 80 column rule 
with tabstop <= 4, but with tabstop > 4 breaks it quite regularly.

By the way, the paren in column 81 is very annoying to me.  It breaks the
indentation flow of the code, as my editor just wraps the line.  I'd
prefer things broken up into multiple lines.  But this is only important
for code I'm heavily working on at the moment.  I don't consider these so
much hard and fast rules that the code nazis will haul you away for
violating, as strong recommendations that you should only break for a good
reason.

One thing I will be code-nazi about: major reformatting should be seperate
checkins from actual code changes.  Checkins of the form "changed the
indentation (touching almost every line in file) and fixed a bug" make 
finding what was changed to fix the bug basically impossible.

Brian

Markus Mottl wrote:
> 
> Hi,
> 
> since we are at it (syntax flamewars): I'd also propose keeping the
> horizontal limit of source lines to 80 characters...

Agreed.

Blair

-- 
Blair Zajac <blair@...>
Plots of your system's performance - http://www.orcaware.com/orca/

Nicolas Cannasse wrote:
> 
> > On Sun, 05 Oct 2003, Nicolas Cannasse wrote:
> > > I agree that short lines are better but I dislike to break some code
> into
> > > several expressions (or shorten identifier name or other tricks) only to
> > > stick to that outdated 80 chars limit.
> >
> > It's outdated in the sense that our displays and printers can handle
> > better than this. The question is whether humans can. Enforcing this
> > (or another) limit keeps people from writing unreadable spaghetti code.
> > Unless you use extremely long identifiers, which should be discouraged
> > in any case, 80 chars should be more than enough.
> 
> Not a flame, but just some comments about that :
> I just don't like such arbitrary rules made in the name of "protecting the
> programmer from writing bad code". I mean, if a programmer is actually that
> bad then he will write unreadable code no matter the chars limit :-)
> Depending on the programming language, on the ident size and naming
> conventions, and many others factors such as the programmer own style of
> programming, this limit can vary a lot. Fixing it to 80 chars is nonsense.

I agree that nothing can protect the bad programmer from writing bad
code.

However, I don't feel that 80 characters is outdated.  I use the high end
laptop work bought me with a 1600x1200 screen (thank you very much :) ) to
open 6 ssh windows at 80 characters and have each one open to a different
file or task in xemacs or in the shell.  So I would like to make a point of
keeping at 80 characters.

Best,
Blair

-- 
Blair Zajac <blair@...>
Plots of your system's performance - http://www.orcaware.com/orca/

On Sun, 2003-10-05 at 21:34, Nicolas Cannasse wrote:

> programming, this limit can vary a lot. Fixing it to 80 chars is nonsense.

80 chars is in fact way too much. 65 is more reasonable.
That is the amount of reasonbly sized monospaced font text
that can be fitted on a book page.

Code should be readable in a fairly constrained viewport.
This has nothing to do with style, but with the limitations
of media.

I learned the hard way typesetting code for publication.
Actual code often goes way over the limit. However it
can be grossly inconvenient. For example I use Vim, and Vim
is super brain dead with horizontal scrolling. I don't fill
up the whole width of my screen with one editor window either.

Don't get me wrong, I often write code that exceeds sensible
line widths. But it is pain, because ALL my code is
literate programmed, and when I typeset it for LaTeX,
it complains bitterly every single time the right margin
is breached.

TeX is GOD when it comes to typesetting quality.
If TeX says badness 30000 for breaching a right
margin, you'd better believe it :-)