Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #7842 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2017-06-18 21:45 +0800 |
| Last post | 2017-07-05 18:36 +0000 |
| Articles | 9 on this page of 29 — 14 participants |
Back to article view | Back to comp.programming
[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]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2017-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]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2017-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]
| From | Simon Wright <simon@pushface.org> |
|---|---|
| Date | 2017-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]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2017-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]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-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]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Adam Jensen <hanzer@riseup.net> |
|---|---|
| Date | 2017-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