Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #7842 > unrolled thread

[BBC] Programmers who use spaces 'paid more'

Started by"Mr. Man-wai Chang" <toylet.toylet@gmail.com>
First post2017-06-18 21:45 +0800
Last post2017-07-05 18:36 +0000
Articles 9 on this page of 29 — 14 participants

Back to article view | Back to comp.programming


Contents

  [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-18 21:45 +0800
    Re: [BBC] Programmers who use spaces 'paid more' Per Sandberg <per.s.sandberg@bahnhof.se> - 2017-06-18 22:13 +0200
      Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-18 19:03 -0400
        Re: [BBC] Programmers who use spaces 'paid more' Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-18 20:22 -0400
          Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-18 22:20 -0400
        Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-19 07:50 +0200
          Re: [BBC] Programmers who use spaces 'paid more' Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 07:24 +0000
          Re: [BBC] Programmers who use spaces 'paid more' Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 08:28 +0000
          Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 22:28 +0800
        Re: [BBC] Programmers who use spaces 'paid more' Snit <usenet@gallopinginsanity.com> - 2017-06-19 20:00 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 18:46 +0800
    Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-18 18:19 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-18 22:23 -0400
        Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-19 12:42 -0700
          Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-19 22:19 -0400
            Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 11:44 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 18:47 +0800
        Re: [BBC] Programmers who use spaces 'paid more' nospam@please.invalid (AnthonyL) - 2017-06-19 11:24 +0000
          Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 20:26 +0800
    Re: [BBC] Programmers who use spaces 'paid more' JJ <jj4public@vfemail.net> - 2017-06-19 20:53 +0700
      Re: [BBC] Programmers who use spaces 'paid more' Julio Di Egidio <julio@diegidio.name> - 2017-06-19 07:11 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 22:27 +0800
      Re: [BBC] Programmers who use spaces 'paid more' Anton Shepelev <anton.txt@gmail.com> - 2017-06-21 00:51 +0300
        Re: [BBC] Programmers who use spaces 'paid more' Julio Di Egidio <julio@diegidio.name> - 2017-06-20 14:56 -0700
    Re: [BBC] Programmers who use spaces 'paid more' Simon Wright <simon@pushface.org> - 2017-06-21 13:27 +0100
      Re: [BBC] Programmers who use spaces 'paid more' Julio Di Egidio <julio@diegidio.name> - 2017-06-21 05:36 -0700
    Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-21 18:48 +0200
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-22 00:52 +0800
      Re: [BBC] Programmers who use spaces 'paid more' Adam Jensen <hanzer@riseup.net> - 2017-07-05 18:36 +0000

Page 2 of 2 — ← Prev page 1 [2]


#7859

FromJulio Di Egidio <julio@diegidio.name>
Date2017-06-19 07:11 -0700
Message-ID<788850ef-b81a-483b-9c24-b8964f089c3e@googlegroups.com>
In reply to#7858
On Monday, June 19, 2017 at 3:53:48 PM UTC+2, JJ wrote:
> On Sun, 18 Jun 2017 21:45:16 +0800, Mr. Man-wai Chang wrote:
<snip>
> > Professional developers typically set up their coding editor to use 
> > either tabs or spaces to show the relationships between functional 
> > elements, he said. Code can get harder to read if viewed in an editor 
> > expecting tabs and getting spaces or vice versa.
> 
> Tab characters are annoying.

It's funny and tragic at the same time to hear all the non-sense about
any topic software production...  Tabs are in fact the way to go for
indentation, they have the abstract meaning of one tab per level of
indentation, and how to present that is just the job of an editor: some
editors are broken, the rest is the usual band-wagon, i.e. speculations,
sabotaging, and of course the widespread incompetence that goes with it.

Julio

[toc] | [prev] | [next] | [standalone]


#7860

From"Mr. Man-wai Chang" <toylet.toylet@gmail.com>
Date2017-06-19 22:27 +0800
Message-ID<oi8mp9$jqb$2@dont-email.me>
In reply to#7858
On 19/6/2017 9:53 PM, JJ wrote:
> 
> Tab characters are annoying. They messes the cursor's column position when
> it's being moved up/down and through the middle of the non existing space
> which was generated by the tab character.

I think that depends on the editor you were using. Or is it a Window$ 
Win32 objects behavior? I frankly don't know.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]


#7869

FromAnton Shepelev <anton.txt@gmail.com>
Date2017-06-21 00:51 +0300
Message-ID<20170621005131.3a80ed65ff72d9119bccfa73@gmail.com>
In reply to#7858
JJ:

> Tab characters are annoying.  They messes the cur-
> sor's  column  position  when  it's  being   moved
> up/down and through the middle of the non existing
> space which was generated by the tab character.

There is a standard convention that  works  100%  of
the time:
                 Indent with tabs
                 Align with spaces

Such code will look good regardless of the tab width
used in the editor, so that each programmer may  set
up whatever tab width he prefers.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]


#7870

FromJulio Di Egidio <julio@diegidio.name>
Date2017-06-20 14:56 -0700
Message-ID<660dfd7f-cad2-45ad-b2c6-4c073b7b14c6@googlegroups.com>
In reply to#7869
On Tuesday, June 20, 2017 at 11:51:24 PM UTC+2, Anton Shepelev wrote:
> JJ:
> 
> > Tab characters are annoying.  They messes the cur-
> > sor's  column  position  when  it's  being   moved
> > up/down and through the middle of the non existing
> > space which was generated by the tab character.
> 
> There is a standard convention that  works  100%  of
> the time:
>                  Indent with tabs
>                  Align with spaces
> 
> Such code will look good regardless of the tab width
> used in the editor, so that each programmer may  set
> up whatever tab width he prefers.

+1

Julio

[toc] | [prev] | [next] | [standalone]


#7871

FromSimon Wright <simon@pushface.org>
Date2017-06-21 13:27 +0100
Message-ID<lyvanp4jaz.fsf@pushface.org>
In reply to#7842
"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> The debate over whether it is better to use spaces or tabs to indent
> code has raged among programmers for years.

Dead simple: use the TAB key to tell the editor to align the
current/selected lines appropriately; and leave the editor to decide
whether to use tab characters (C-I) to implement the indent or just
spaces.

I agree that you have a problem if your project standards require some
weird setting, but it's still a question of customising the editor.

I bet that 90+% of the Ada programmers who've read this thread are using
GNAT, and if they are using either of the most likely editors (GPS or
Emacs) they'll have this sorted for them without any need for fretting
over it.

Anyone who argues for tabs on the grounds that they save space is
clearly living in 1987 at the latest. If you want to save space, why not
remove all comments?

[toc] | [prev] | [next] | [standalone]


#7872

FromJulio Di Egidio <julio@diegidio.name>
Date2017-06-21 05:36 -0700
Message-ID<4b37fa30-c11d-4d7d-80c5-c70078e4615f@googlegroups.com>
In reply to#7871
On Wednesday, June 21, 2017 at 2:27:57 PM UTC+2, Simon Wright wrote:

> Dead simple: use the TAB key to tell the editor to align the
> current/selected lines appropriately; and leave the editor to decide
> whether to use tab characters (C-I) to implement the indent or just
> spaces.

Back to plain nonsense...

Julio

[toc] | [prev] | [next] | [standalone]


#7873

From"Pascal J. Bourguignon" <pjb@informatimago.com>
Date2017-06-21 18:48 +0200
Message-ID<m2k2458ey1.fsf@informatimago.com>
In reply to#7842
"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> Computer programmers who use spaces as part of their coding earn
> $15,370 (£12,000) more per year than those who use tabs, a survey of
> developers has revealed.
>
> Full story: <http://www.bbc.com/news/technology-40302410>

It is said that line prefixes in the form of: TAB* SPC{0,tw-1}
are the best of both world.

This is false.

First, you would need an editor to enforce it.

But it doesn't even solve the first problem of TAB, that their width
varies depending on tools and devices.

The problem is that the sequence of spaces must be of a length less than
the TAB width.  So if you start with tw₀ and have sequences of SPC of
length tw₀-1, and you read/process the file on another system using
tw₁<tw₀, then you will get wrong indentations.

Furthermore, when you allow TAB in source files, you may also use them
to align columns of code, eg. to align variable names in one column, and
types in another column.  And for those TAB in the middle of the lines,
the above rule is helpless, and again, you will get wrong indentations
in other environments, but also IN THE SAME ENVIRONMENT, where the TAB
width is kept constant, as soon as you use a different FONT, notably
when you use non-proportional fonts.

I know that it may seem heritic to use non-proportional fonts for code,
but the reality is that it can work very well, as long as you solve in
the IDE those problems of indentation, both prefix and inside a line.

And, it means the editor will have to compute the layout all the time,
from the parse tree.

Which leads me to the conclusion that the origin of a lot of problems is
the fact that we save "source" files that are used as-is both for
human presentation/edition and for machine processing (compiling).  I
would propose the alternative to save the programs eg. in the form of an
abstract syntactic tree (let's say lisp S-expressions), and each time it
is loaded in an IDE/editor, it would be unparsed into the specific
syntactic and layout/indenting preferences of the programmer; and when
saved, the programmer specific syntax would be parsed, and the
S-expression syntactic tree would be saved to the file.  Machine
processing can use directly these S-expression forms.

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]


#7874

From"Mr. Man-wai Chang" <toylet.toylet@gmail.com>
Date2017-06-22 00:52 +0800
Message-ID<oie82e$jqb$1@dont-email.me>
In reply to#7873
On 22/6/2017 12:48 AM, Pascal J. Bourguignon wrote:
> Which leads me to the conclusion that the origin of a lot of problems is
> the fact that we save "source" files that are used as-is both for
> human presentation/edition and for machine processing (compiling).  I
> would propose the alternative to save the programs eg. in the form of an
> abstract syntactic tree (let's say lisp S-expressions), and each time it
> is loaded in an IDE/editor, it would be unparsed into the specific
> syntactic and layout/indenting preferences of the programmer; and when
> saved, the programmer specific syntax would be parsed, and the
> S-expression syntactic tree would be saved to the file.  Machine
> processing can use directly these S-expression forms.

Basically, a code beautifier. But some programming languages' CR and LF 
mean something. In the case of COBOL, the first few columns have meanings.

Which makes me believe hard, true SPACE is a simple and better solution. 
Anyway....

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]


#7908

FromAdam Jensen <hanzer@riseup.net>
Date2017-07-05 18:36 +0000
Message-ID<ojjbj8$jhu$1@dont-email.me>
In reply to#7873
On Wed, 21 Jun 2017 18:48:22 +0200, Pascal J. Bourguignon wrote:

[snip]
> Which leads me to the conclusion that the origin of a lot of problems is
> the fact that we save "source" files that are used as-is both for human
> presentation/edition and for machine processing (compiling).  I would
> propose the alternative to save the programs eg. in the form of an
> abstract syntactic tree (let's say lisp S-expressions), and each time it
> is loaded in an IDE/editor, it would be unparsed into the specific
> syntactic and layout/indenting preferences of the programmer; and when
> saved, the programmer specific syntax would be parsed, and the
> S-expression syntactic tree would be saved to the file.  Machine
> processing can use directly these S-expression forms.

That's interesting. I am also surprised that the representation of 
"programming languages" and "source code" documents haven't really 
changed much. For example, it seems like a system of XML-based documents 
could represent the essential "program", the documentation, and the 
dependencies, with all of the various layers and dimensions of annotation 
such that various aspects and views could be presented to humans 
(engineers, students, etc.) and automata (compilers, analyzers, etc.). I 
think standards and test-suites, procedures and work-flows, definitions 
and descriptions, examples and explanations, could/should all be 
represented along with the tools and programs in this system of documents 
that would represent a coherent information system. 

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.programming


csiph-web