Re: OT - trivial programming language
On Sat, May 29, 2004 at 04:50:09PM -0500, dircha wrote:
> Kai Grossjohann wrote:
> >Steve Lamb <grey@dmiyu.org> writes:
> >>if (foo){
> >> if (bar){
> >> foreach $foo (@bar){
> >> while $foo < $baz{
> >> some really long and convoluted computation here
> >> }
> >> }
> >> }
> >>}
> >>
> >>Now expand that out to someone's preferred 8 per line (ewwwww) and
> >>you'll see that the "some really long and convoluted computation
> >>here" is wrapping. On my screen it looks reasonable, on someone
> >>else's it looks like crap.
> >
> >Well, nothing that couldn't be solved with a somewhat wider window.
> >Many people like to have windows wider than 80 columns. (I prefer 80
> >columns, myself.)
>
> This is not an adequate response to scenario's similar to what Steve
> illustrates here. I will elaborate below.
>
> >>It is because of this mixing of tabs and spaces that people rigidly
> >>say that tabs should never be changed from 8 character widths.
> >
> >The style I'm proposing is designed to make it possible to change tab
> >width!
>
> It does not work.
>
> Consider the problems created with a code file created by a user who
> prefers 8-character-width tabs _and_ 80 columns.
>
> Now, when someone who prefers 4-character-width tabs and 80 columns
> wishes to collaborate on this document, he or she will find lines
> wrapped at ~65-75 characters as they were originally wrapped for
> 8-character-width tabs and 80 columns.
>
Actually the best method when collaborating on someone else's work is
to adopt their coding style. If its a joint work then you should a
agree on a coding style in the first place.
Any indentation style will usually be ok as long as it is
consistent. Trouble starts when different people use different
indentation style in the same project.
On my last job, every new programmer had as part of the training to
read the coding style specifications for the company, and in properly
collaborated projects its supposed to be very hard to notice which parts
were written by which programmers.
> In this case the 4-character-width tabs user has only one option to
> retain a style acceptable for use by the 8-character-width tabs user. He
> or she must wrap lines such that for a given line, were it displayed
> with 8-character-width tabs, it would still fit within 80 columns.
>
> First, this requires that the user perform a tab width calculation for
> each wrapping to determine where it would wrap were it displayed with
> 8-character-width tabs. Second, this defeats the original intention of
> the 4-character-width tabs user in using 4-character-width tabs: to use
> a indent width he or she can more easily follow visually and while at
> the same time making more effective use of 80 columns for complex code.
>
> As illustrated by Steve's example above, in either direction of
> conversion, your proposal may as well be to mandate that the tab width
> and column width of the original environment for all collaborating
> users, because for your proposal to work, you must deny the user the
> ability to reap the advantages of his or her preferred environment.
>
> The best proposal is to mandate a fixed tab width or spaces per indent
> level, and mandate wrapping for a fixed column width.
>
> I'm ready to argue that this should generally be 4-character spaces and
> 80 column wrapping.
>
> dircha
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
Reply to: