Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60096 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2015-04-15 11:46 -0700 |
| Last post | 2015-04-30 01:40 -0700 |
| Articles | 20 on this page of 318 — 32 participants |
Back to article view | Back to comp.lang.c
Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 11:46 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-15 19:55 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:00 -0700
Re: Readability part I - code Xcott Craver <xcottcraver@gmail.com> - 2015-04-15 13:19 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-16 13:08 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:25 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-04-16 01:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:37 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-05-01 02:07 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:29 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:13 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:34 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:46 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-04-30 05:54 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:37 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-01 11:48 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-02 23:59 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 20:52 +0000
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-08 16:15 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-09 16:14 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:11 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 00:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:51 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-30 20:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 05:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-01 06:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:17 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-16 11:01 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 04:26 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-16 13:19 -0500
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 09:20 +0200
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-04-17 08:21 -0400
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 15:04 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 06:18 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-17 12:24 -0500
Re: Readability part I - code Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-17 15:58 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 04:10 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 13:47 +0200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-04-30 13:48 +0100
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 16:35 +0200
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-04-30 10:00 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 06:25 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-02 15:53 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:42 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-04 09:41 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 07:01 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-06 09:34 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 04:33 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:51 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:51 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-07 21:49 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 13:22 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 15:27 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 21:00 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 00:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-06 13:11 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:48 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:26 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 16:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 20:22 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-08 02:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-08 10:53 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:30 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-08 09:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-08 11:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-09 09:31 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:01 +1200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-09 13:13 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:51 +1200
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-09 16:45 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:28 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:36 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-05-06 22:13 -0500
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:56 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 14:16 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:02 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:36 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 15:09 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 17:13 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:07 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-08 11:35 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:41 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 10:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-10 10:50 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-10 19:09 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 04:54 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 13:19 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-12 05:26 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:31 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:40 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 10:28 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-10 11:39 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 05:33 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 17:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 09:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:37 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:46 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:53 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:47 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 20:04 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 12:39 -0700
Re: Readability part I - code Nathan Wagner <nw@hydaspes.if.org> - 2015-05-12 07:34 +0000
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 10:58 +0000
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 21:00 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:18 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 23:37 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 00:07 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 16:52 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 01:19 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 01:43 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 11:00 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 12:33 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 13:25 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:01 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:26 -0700
Re: Readability part I - code Ike Naar <ike@iceland.freeshell.org> - 2015-05-14 19:58 +0000
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 20:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:25 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 08:50 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-25 02:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:25 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:35 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 15:53 +0100
Re: Readability part I - code Martin Shobe <martin.shobe@yahoo.com> - 2015-07-10 10:20 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 16:30 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 10:49 -0700
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-10 11:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:47 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-13 20:20 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 02:57 -0700
Re: Readability part I - code "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-13 12:27 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:35 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-15 18:46 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-15 11:35 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:47 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 21:24 +0000
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 08:43 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-21 13:26 -0400
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 22:11 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-22 04:03 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:30 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:14 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 08:24 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 23:39 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-22 11:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-23 07:35 +1200
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:36 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:25 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 08:44 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-10 16:53 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:57 -0700
Re: Readability part I - code Öö Tiib <ootiib@hot.ee> - 2015-05-23 06:27 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-23 16:07 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-23 19:10 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:25 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 12:24 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:49 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 12:49 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:56 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:07 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:29 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:52 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 19:45 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:27 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:50 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:48 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-23 21:30 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 11:30 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:16 -0500
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-26 23:04 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:12 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-12 17:28 +1200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:43 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:16 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:34 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 22:52 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:45 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 12:53 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-21 11:01 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 20:18 +0100
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 21:47 +0100
Re: Readability part I - code Kusalananda <kusalananda@example.com> - 2015-05-24 07:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:18 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:15 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:53 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-11 14:09 +1200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 10:37 +0800
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 12:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-12 10:20 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 07:23 -0700
Re: Readability part I - code jadill33@gmail.com - 2015-05-11 13:30 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:14 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:15 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:38 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:38 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 17:58 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 13:44 -0500
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:32 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 11:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-21 08:41 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 18:12 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 19:20 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:35 -0700
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 14:54 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 15:10 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:51 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 13:22 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:47 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 17:05 -0700
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 11:04 +0200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 18:06 +0800
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 14:57 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 09:20 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:06 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:55 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 13:26 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 06:29 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 13:49 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:12 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 15:26 +0000
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-22 11:36 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 23:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:42 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:37 +0000
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 10:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 16:47 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-16 17:03 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 06:52 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:23 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:52 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 09:29 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-24 14:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:30 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:04 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-10 18:39 -0500
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:02 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 01:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:48 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:50 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 06:55 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 15:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:14 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:53 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 22:04 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 14:51 -0700
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-11 20:05 -0400
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:31 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 18:24 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 19:00 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-13 13:24 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-13 06:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 23:21 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:35 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:43 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 10:31 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 16:12 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 18:02 +0100
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-12 11:16 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 21:06 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:44 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:13 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:01 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:28 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:53 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:45 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:55 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 02:44 +0000
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-12 16:51 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:25 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-11 09:25 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:15 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 16:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:35 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 11:53 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 20:01 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:09 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:43 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-25 14:51 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-26 09:17 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:44 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:19 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 14:04 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 08:07 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-02 09:18 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-03 10:43 -0700
Re: Readability part I - code Melzzzzz <mel@zzzzz.com> - 2015-05-03 19:47 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 13:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 06:45 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-05 09:06 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 20:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:33 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:33 -0700
Re: Readability part I - code Les Cargill <lcargill99@comcast.com> - 2015-04-16 12:28 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:42 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 01:40 -0700
Page 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-12 16:47 -0700 |
| Message-ID | <kfniobxbbpc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61851 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 11-May-15 11:20, Tim Rentsch wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>> Adding "unnecessary" spaces or parentheses can make some
>>> expressions more clear, but adding too many can instead make them
>>> less clear--and I tend to err on the side of too few simply so
>>> more code fits on the screen. Ditto for why I prefer 1TBS
>>> brace/indent style.
>>
>> There are several different aspects here, let me ask about them
>> one at a time. First about conserving spaces.
>>
>> Consider the following two expression statements, which differ
>> only in spacing (and assume both fit easily on the line where
>> they would appear, including indentation etc):
>>
>> (1) printf("foo[ %2d ] is %9.2f\n",i,foo[i]);
>> (2) printf( "foo[ %2d ] is %9.2f\n", i, foo[i] );
>>
>> Would you say
>>
>> (a) (1) is markedly easier to read than (2)
>> (b) (1) is slightly easier to read than (2)
>> (c) (1) and (2) are about the same in ease of reading
>> (d) (2) is slightly easier to read than (1)
>> (e) (2) is markedly easier to read than (1)
>
> I'd have to answer (b) here, but mainly because I find the extra
> spaces inside the parentheses to be more jarring than the lack of
> spaces after the commas. This is my preferred form:
>
> (3) printf("foo[ %2d ] is %9.2f\n", i, foo[i]);
>
>> If the answer is other than (c), what cognitive or perceptual
>> factors play a role in that? To what extent are these influenced
>> mostly by what you are used to, as opposed to being inherent in
>> the neurological "hardware" or "firmware" that does the reading?
>
> I find my version significantly easier to read than _either_ of
> yours, but probably in large part simply due to that being what I'm
> used to. In particular, whether to use a space after commas was
> learned over a lifetime of reading English text and Arabic numbers:
> use a space when it's a list separator but not when it's solely for
> visual grouping.
Okay, this answers my question quite nicely.
>> I think most developers would agree that there is a tension
>> between expressing code compactly and limiting visual density.
>> Do you agree with this principle? Where would you put yourself
>> on the compactness/openness spectrum (and I admit the labels
>> I'm using are pretty vague):
>
> I don't think I can answer this generally or objectively; I use the
> minimum amount of spacing necessary for the code to be subjectively
> readable, and that depends on the _exact_ code in question.
Okay, based on that I would say you're probably between (a) and
(b), and if forced to pick just one would say (b). For myself I
think between (c) and (d), and if forced to pick just one would
probably say (d).
>> Considering these two forms of if(),
>>
>> (1) if (a == b) {
>> (2) if( a == b ){
>>
>> the same amount of horizontal space is used. Does this mean that
>> your wanting to conserve spaces does not influence the question
>> of which of the two is preferable? If not then why not?
>
> I would never write the latter since it makes if look like a
> function call, and I'd also put a space between the parenthesis and
> the brace since the former is more clearly connected to the
> expression than the block that follows, so this is the real
> comparison:
>
> (1) if (a == b) {
> (2) if ( a == b ) {
>
> And, in that case, I'd clearly prefer the former.
That is _a_ comparison, but it is not the comparison I'm
interested in. Also, my question is specifically about spacing
and you wanting to conserve them. So even though your answer
gave some information, I didn't really find out what I was
trying to ask about. Can I ask you to read the question
again? (I should clarify the second part: "If your answer
to the previous question is 'conserving spaces does influence
choosing between them' then please explain how.")
>> In broad terms I'm not sure how much of what you say is about how
>> you think code should be written (for whatever considerations),
>> and how much is about how easy to read (or not) the different
>> results are.
>
> It's all about the ease of reading--even if it's just me reading it
> again while I work on other parts of the same function.
>
> As to _why_ one form seems more readable than another, I think it's
> mostly indirect--probably entirely indirect other than cases where
> the spacing directly affects how much code appears on a single
> screen.
The second paragraph baffles me. If putting more spaces on a
line wouldn't cause it to grow over a line width limit, how
does spacing (or not spacing) on that line affect the readability
of anything else? If putting more spaces on a line would cause
it to grow over a line width limit, and hence limiting spaces
means more code (or longer functions) can be visible, doesn't
that seem like an indirect benefit? I don't see what you're
trying to say here.
>> Digressing slightly, I can't resist asking a question about
>> vertical spacing. I am also a fan of 1TBS (shameless editorial
>> comment - as any sensible person would be).
>
> Well, it's called 1TBS for a reason :)
>
> I don't mind most others, but GNU indenting is an abomination.
>
>> Do you often run into cases where line width exceeds (or would
>> exceed, if not addressed) the nominal limit? Or to ask that
>> another way, do you often see cases where a "logical line" needs
>> to be continued across more than on physical line?
>
> Yes, though I'll point out it's usually due to functions that take
> too many arguments, which is arguably poor interface design.
I meant to ask only about lines inside function bodies. I put
parameter declarations (ie, in prototypes - K&R style parameters
are totally off the map here) in a different category.
> My own
> code usually consists of many short statements, to help make the
> code clearer and self-documenting. The dislike of long lines seems
> to go against my distaste for wasting space, and I'm not sure how I
> reconcile that.
Okay... when you do I would be very interested to hear what
you come up with.
> Note that I prefer my monitors in portrait mode (tall and narrow),
> which is the opposite of most users and traditional terminals.
I don't think that matters very much as long as you observe
line width limits of something close to 80 columns. I guess
it could slightly skew the results to favor longer functions
with narrower-on-the-average lines. Can I ask how tall in
lines of text your usual setup gives you?
>> Also, related to that, how much indentation per nesting level are
>> you accustomed to (a multi-valued answer definitely possible here)?
>
> I'm used to 2, 4 and 8 spaces, depending on which environment I'm
> in; I prefer to keep my tab stops at 2 spaces, but some projects
> use spaces rather than tabs--or worse, a mixture--and I have to
> reset to 8.
>
> As to why 2 spaces, that's because it's the minimum for each level
> to be visually distinct; I'd use 1 if it were sufficient.
Okay, good answer. If you're interested my own choice point (to
keep things simple, considering just {2,4,8} as choices) is 4
spaces, balancing using up space and reading burden. With 2
space indentation I can tell the different levels apart but
sometimes I have to look and check, which I almost never do
with 4.
>> as an average, what would you say is a reasonable amount of intra-
>> function-definition blank lines, considering just the body of each
>> function (and not the open/close brace lines), rounded to the nearst
>> 5%:
>
> Mu. If you need to separate sections of code within a function for
> clarity, then use one blank line as a separator. Aside from the
> break between variable declarations and statements, which is
> disappearing due to inline declarations, this is often a sign that
> your function should be broken up into separate ones, or some of the
> code should be moved to a helper function.
Sorry, the way I asked this question was awful. Let me try
again. If you write code just the way that seems right to
you, considering subjective aesthetics, factoring, function
composition and whatever else you think is appropriate, what
is the result in terms of percentage of blank lines per line
of function body? Of course you could measure actual code and
report that, but what I'm asking is just what you think the
number is, or range, whatever - what is your best guess for
code written like you think it ought to be written?
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-16 17:03 -0500 |
| Message-ID | <mj8eps$4ot$1@dont-email.me> |
| In reply to | #61929 |
On 12-May-15 18:47, Tim Rentsch wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
>> On 11-May-15 11:20, Tim Rentsch wrote:
>>> I think most developers would agree that there is a tension
>>> between expressing code compactly and limiting visual density.
>>> Do you agree with this principle? Where would you put yourself
>>> on the compactness/openness spectrum (and I admit the labels
>>> I'm using are pretty vague):
>>
>> I don't think I can answer this generally or objectively; I use the
>> minimum amount of spacing necessary for the code to be subjectively
>> readable, and that depends on the _exact_ code in question.
>
> Okay, based on that I would say you're probably between (a) and
> (b), and if forced to pick just one would say (b). For myself I
> think between (c) and (d), and if forced to pick just one would
> probably say (d).
Fair enough.
>>> Considering these two forms of if(),
>>>
>>> (1) if (a == b) {
>>> (2) if( a == b ){
>>>
>>> the same amount of horizontal space is used. Does this mean that
>>> your wanting to conserve spaces does not influence the question
>>> of which of the two is preferable? If not then why not?
>>
>> I would never write the latter since it makes if look like a
>> function call, and I'd also put a space between the parenthesis and
>> the brace since the former is more clearly connected to the
>> expression than the block that follows, so this is the real
>> comparison:
>>
>> (1) if (a == b) {
>> (2) if ( a == b ) {
>>
>> And, in that case, I'd clearly prefer the former.
>
> That is _a_ comparison, but it is not the comparison I'm
> interested in.
I said I'd never write your (2), and explained why, so I would prefer
your (1), but perhaps that wasn't as obvious as I thought it was.
In your comparison, there's clearly no difference in total length, so
that's not a factor--but it becomes a factor in mine.
>> As to _why_ one form seems more readable than another, I think it's
>> mostly indirect--probably entirely indirect other than cases where
>> the spacing directly affects how much code appears on a single
>> screen.
>
> The second paragraph baffles me. If putting more spaces on a
> line wouldn't cause it to grow over a line width limit, how
> does spacing (or not spacing) on that line affect the readability
> of anything else?
As is commonly said, the most important thing about style is being
consistent, moreso than the particular style chosen. So, even when the
amount of whitespace _doesn't_ affect how much code fits on a given
line, one must be consistent with lines where it _does_ matter.
>>> Do you often run into cases where line width exceeds (or would
>>> exceed, if not addressed) the nominal limit? Or to ask that
>>> another way, do you often see cases where a "logical line" needs
>>> to be continued across more than on physical line?
>>
>> Yes, though I'll point out it's usually due to functions that take
>> too many arguments, which is arguably poor interface design.
>
> I meant to ask only about lines inside function bodies. I put
> parameter declarations (ie, in prototypes - K&R style parameters
> are totally off the map here) in a different category.
I was actually thinking of function calls here, especially when they are
used in a longer expression or one or more of the arguments are long
expressions themselves; function declarations and definitions can be
problematic as well, but IME less often.
>> My own
>> code usually consists of many short statements, to help make the
>> code clearer and self-documenting. The dislike of long lines seems
>> to go against my distaste for wasting space, and I'm not sure how I
>> reconcile that.
>
> Okay... when you do I would be very interested to hear what
> you come up with.
After thinking about it, I suppose I feel short lines reduce the need
for comments, so even though it looks like I'm wasting vertical space,
not needing comments probably makes it a wash.
>> Note that I prefer my monitors in portrait mode (tall and narrow),
>> which is the opposite of most users and traditional terminals.
>
> I don't think that matters very much as long as you observe
> line width limits of something close to 80 columns. I guess
> it could slightly skew the results to favor longer functions
> with narrower-on-the-average lines. Can I ask how tall in
> lines of text your usual setup gives you?
That depends on the window size, of course, but ~60 lines for a
maximized window with my current font/DPI settings, i.e. about one
printed page.
>>> Also, related to that, how much indentation per nesting level are
>>> you accustomed to (a multi-valued answer definitely possible here)?
>>
>> I'm used to 2, 4 and 8 spaces, depending on which environment I'm
>> in; I prefer to keep my tab stops at 2 spaces, but some projects
>> use spaces rather than tabs--or worse, a mixture--and I have to
>> reset to 8.
>>
>> As to why 2 spaces, that's because it's the minimum for each level
>> to be visually distinct; I'd use 1 if it were sufficient.
>
> Okay, good answer. If you're interested my own choice point (to
> keep things simple, considering just {2,4,8} as choices) is 4
> spaces, balancing using up space and reading burden. With 2
> space indentation I can tell the different levels apart but
> sometimes I have to look and check, which I almost never do
> with 4.
Fair enough, though that's probably one of the least important style
questions--as long as folks use actual tabs rather than spaces--since
each user can set their editor for their preference.
>>> as an average, what would you say is a reasonable amount of intra-
>>> function-definition blank lines, considering just the body of each
>>> function (and not the open/close brace lines), rounded to the nearst
>>> 5%:
>>
>> Mu. If you need to separate sections of code within a function for
>> clarity, then use one blank line as a separator. Aside from the
>> break between variable declarations and statements, which is
>> disappearing due to inline declarations, this is often a sign that
>> your function should be broken up into separate ones, or some of the
>> code should be moved to a helper function.
>
> Sorry, the way I asked this question was awful. Let me try
> again. If you write code just the way that seems right to
> you, considering subjective aesthetics, factoring, function
> composition and whatever else you think is appropriate, what
> is the result in terms of percentage of blank lines per line
> of function body? Of course you could measure actual code and
> report that, but what I'm asking is just what you think the
> number is, or range, whatever - what is your best guess for
> code written like you think it ought to be written?
I've never thought about it this way, so without cheating, my best guess
is that it'd be in the ballpark of 10%.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-23 06:52 -0700 |
| Message-ID | <kfnk2vz8kqk.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62132 |
Stephen Sprunk <stephen@sprunk.org> writes: > On 12-May-15 18:47, Tim Rentsch wrote: >> Stephen Sprunk <stephen@sprunk.org> writes: >>> On 11-May-15 11:20, Tim Rentsch wrote: > > [snip] Answers all good - I understand now (at least mostly) what you were trying to say on all of them. >> If putting more spaces on a line wouldn't cause it to grow over a >> line width limit, how does spacing (or not spacing) on that line >> affect the readability of anything else? > > As is commonly said, the most important thing about style is being > consistent, moreso than the particular style chosen. So, even > when the amount of whitespace _doesn't_ affect how much code fits > on a given line, one must be consistent with lines where it _does_ > matter. Okay, I see now what you meant. Natural followup question - if you used more liberal spacing everywhere, what would be the consequence in terms of line overflow (or having to break one statement into two to avoid overflow, which is basically the same thing)? In other words how often would more horizontal spacing result in more vertical space being needed? >> I meant to ask only about lines inside function bodies. I put >> parameter declarations (ie, in prototypes - K&R style parameters >> are totally off the map here) in a different category. > > I was actually thinking of function calls here, especially when > they are used in a longer expression or one or more of the > arguments are long expressions themselves; function declarations > and definitions can be problematic as well, but IME less often. I see, that makes more sense than how I first read it. How to deal with long function calls is a whole other subtopic, so let me just say my reaction is similar to yours and leave anything further for another time. > After thinking about it, I suppose I feel short lines reduce the > need for comments, so even though it looks like I'm wasting > vertical space, not needing comments probably makes it a wash. When you say it looks like you're wasting vertical space, does that mean because you put in blank lines now and then? I don't think of judicious use of blank lines as wasting vertical space, any more than I think of judicious use of spaces as wasting horizontal space. By the way, even though I understand your answer, I'm still somewhat at a loss to see why you feel that way (especially since to me more horizontal spacing would do the same, but let's disregard that). Rather than asking for further explanation what I think would be more helpful is to see some of your code and look at it in light of your other answers. So if you feel inclined to make something available at some point I would be interested to take a look. >> If you write code just the way that seems right to you, considering >> subjective aesthetics, factoring, function composition and whatever >> else you think is appropriate, what is the result in terms of >> percentage of blank lines per line of function body? Of course you >> could measure actual code and report that, but what I'm asking is >> just what you think the number is, or range, whatever - what is >> your best guess for code written like you think it ought to be >> written? > > I've never thought about it this way, so without cheating, my best > guess is that it'd be in the ballpark of 10%. Yes, I think that's about what I would say (or would have said) if I had to guess. After asking, I got curious, and did some measurements on a couple dozen sets of .c files (having deliberately thrown out some outliers). The results were a little surprising. There was a fairly large range, between about 6% and 18%, and it didn't seem to correlate particularly with other obvious metrics - code size, number of functions, or average function size. So different kinds of problems appear to have different characteristics as regards use of vertical spacing. Thank you again for taking the time to discuss this stuff. I think it helps to try to understand other people's points of view, and your comments have (for me at least) done a lot for that.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-11 11:23 -0700 |
| Message-ID | <kfnfv73dlct.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61733 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 07-May-15 15:36, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same
>>> reason.
>>
>> That's fine but you don't say what factors influence that. Can
>> you say anything about what those are? Might it be that you
>> find the first form easier just because that's what you are
>> used to?
>
> Since Keith didn't have anything to say, but my preference is
> similar ('if (a==b)'), I'll take a stab at it.
Continuing now with my second followup. (By the way your
writing in this posting is very good.)
> First, 'if( ... )' looks too much like a function call; it's not,
> so I prefer 'if ( ... )'.
>
> Second, '( ... )' wastes space, and I prefer parentheses visually
> bound to what they're containing: '(...)'.
>
> [snip more re: spacing]
First a general question. I understand that the choices you
mention are your preferences. To what extent do you find code
written not following these preferences hard to read? To say
that another way, how much does the choice affect ease of reading
(in particular, for you)? What of the following factors are
relevant?
(a) perceptual
(b) cognitive
(c) being familiar or accustomed (or lack thereof)
(d) indirect effects
(e) no effect on ease of reading (or other?)
Concerning adjacency, you say you prefer parentheses be visually
bound (to what's inside) but you don't say why. Can you explain
this beyond just saying it's what you prefer? In particular,
does putting spaces inside the parentheses make it harder for you
to read the result, or do you dislike it just because it's not
what you prefer? Speaking for myself, I find it natural to put
parentheses next to what's inside them when the whole is an
expansion from primary-expression, but generally not for other
places in the syntax where parentheses appear for just a part
of one right-hand-side. So for me the different kinds of roles
played in the syntax makes a difference for how I read them.
Concerning similarity to function calls, how big do you think
the effect is here? Do you normally write function calls with
spaces inside the parentheses? That would seem to violate both
the conserve spaces principle and the adjacency principle. If
you don't usually put spaces inside function call parentheses,
then 'if( a == b )' doesn't look the same as a function call.
It seems like there's an inconsistency somewhere.
Something that was snipped from a comment made upthread is my
rule to normally put two spaces inside (each of) the parentheses
that go with if(), while(), etc. Doing that makes if() etc
noticeably distinct compared to function calls. Introspecting a
bit, I also realize that the spaces correspond to a mental pause
that occurs (and I think there is a benefit that it does), when
reading an if() etc, to focus on the condition being tested.
This observation leads back to matters of spacing. For me, it's
important for the spacing used to correspond, at least roughly,
to how I chunkify the different parts of a line (and for vertical
spacing, of a function definition). Using varying amounts of
spacing in different circumstances - not just syntactically
different but also semantically different - is therefore a
major factor in what I write and what I find easy (or hard)
to read.
Any reactions?
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-11 23:52 -0500 |
| Message-ID | <mis0t6$p1i$1@dont-email.me> |
| In reply to | #61850 |
On 11-May-15 13:23, Tim Rentsch wrote: > Continuing now with my second followup. (By the way your > writing in this posting is very good.) Thanks :) > First a general question. I understand that the choices you > mention are your preferences. To what extent do you find code > written not following these preferences hard to read? To say > that another way, how much does the choice affect ease of reading > (in particular, for you)? 1TBS seems the most "natural" to me. Allman is a bit jarring at first, but after a few pages, my brain shifts gears and I don't really notice it anymore. I call GNU an abomination because I find it jarring entering or leaving _every single block_; my brain apparently just doesn't have that gear, no matter how much of it I'm forced to suffer through. I once tried to contribute a bug fix to a GNU project, but it was so painful to write even _one function_ in that style, I had to give up before I threw my computer out the window. > What of the following factors are relevant? I appreciate that you're trying to understand, but I'm not sure I even understand the distinctions you're trying to make; I can't really put it any better than "jarring". When I read a novel, my eyes scan very quickly and my brain is several seconds behind them. However, when my subconscious throws a parsing error, I'm forced to go back, locate the source of the problem, and re-parse it consciously, and then restart. Even something as minor as a misplaced comma can drop me from a few seconds per page to a few seconds _per sentence_, and if that happens too often, I usually toss the book rather than continue to suffer. That's what I mean by "jarring". > Stephen Sprunk <stephen@sprunk.org> writes: >> First, 'if( ... )' looks too much like a function call; it's not, >> so I prefer 'if ( ... )'. >> >> Second, '( ... )' wastes space, and I prefer parentheses visually >> bound to what they're containing: '(...)'. > > Concerning adjacency, you say you prefer parentheses be visually > bound (to what's inside) but you don't say why. Can you explain > this beyond just saying it's what you prefer? In particular, > does putting spaces inside the parentheses make it harder for you > to read the result, or do you dislike it just because it's not > what you prefer? It's certainly what I'm used to, but it logically makes more sense to me for the container to be bound to what it's containing, just as there is no space between the milk jug and the milk. To have it bound to nothing makes no sense, but your example was even worse: the container was bound to the adjacent tokens _instead_! > Speaking for myself, I find it natural to put > parentheses next to what's inside them when the whole is an > expansion from primary-expression, but generally not for other > places in the syntax where parentheses appear for just a part > of one right-hand-side. So for me the different kinds of roles > played in the syntax makes a difference for how I read them. Can you give examples? > Concerning similarity to function calls, how big do you think > the effect is here? Do you normally write function calls with > spaces inside the parentheses? That would seem to violate both > the conserve spaces principle and the adjacency principle. If > you don't usually put spaces inside function call parentheses, > then 'if( a == b )' doesn't look the same as a function call. > It seems like there's an inconsistency somewhere. I put spaces after commas in a list, including the list of arguments to a function call, and where they help with clarity. I find this objectionable: if(a) because it looks too much like this: fn(a) In the latter case, the container should be bound to the function name as well as its contents, whereas in the former case, it shouldn't be bound to the conditional: if (a) You may say that the conditional is just as logically bound to the condition as arguments are to a function, but there is some mental distinction that I can't put into words. > Something that was snipped from a comment made upthread is my > rule to normally put two spaces inside (each of) the parentheses > that go with if(), while(), etc. Doing that makes if() etc > noticeably distinct compared to function calls. Introspecting a > bit, I also realize that the spaces correspond to a mental pause > that occurs (and I think there is a benefit that it does), when > reading an if() etc, to focus on the condition being tested. > This observation leads back to matters of spacing. For me, it's > important for the spacing used to correspond, at least roughly, > to how I chunkify the different parts of a line (and for vertical > spacing, of a function definition). Using varying amounts of > spacing in different circumstances - not just syntactically > different but also semantically different - is therefore a > major factor in what I write and what I find easy (or hard) > to read. > > Any reactions? Interesting, and you've obviously put a lot more thought into it than I have. I suppose your way makes sense, but I can't recall having ever seen code written that way, so perhaps it's jarring to me due to lack of familiarity--or perhaps it's an abomination like GNU style :) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-20 09:29 -0700 |
| Message-ID | <kfnegmbb4bm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61880 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 11-May-15 13:23, Tim Rentsch wrote:
>> Continuing now with my second followup. (By the way your
>> writing in this posting is very good.)
>
> Thanks :)
>
>> First a general question. I understand that the choices you
>> mention are your preferences. To what extent do you find code
>> written not following these preferences hard to read? To say
>> that another way, how much does the choice affect ease of reading
>> (in particular, for you)?
>
> 1TBS seems the most "natural" to me. Allman is a bit jarring at
> first, but after a few pages, my brain shifts gears and I don't
> really notice it anymore.
>
> I call GNU an abomination because I find it jarring entering or
> leaving _every single block_; my brain apparently just doesn't
> have that gear, no matter how much of it I'm forced to suffer
> through. I once tried to contribute a bug fix to a GNU project,
> but it was so painful to write even _one function_ in that style,
> I had to give up before I threw my computer out the window.
Yes, I'm sure my reaction would be similar. If I absolutely had
to I would write the function normally and then run it through a
formatter. (Sorry btw for the longish delay in responding, it's
just how things are right now.)
>> What of the following factors are relevant?
>
> I appreciate that you're trying to understand, but I'm not sure I
> even understand the distinctions you're trying to make; I can't
> really put it any better than "jarring".
>
> When I read a novel, my eyes scan very quickly and my brain is
> several seconds behind them. However, when my subconscious throws
> a parsing error, I'm forced to go back, locate the source of the
> problem, and re-parse it consciously, and then restart. Even
> something as minor as a misplaced comma can drop me from a few
> seconds per page to a few seconds _per sentence_, and if that
> happens too often, I usually toss the book rather than continue to
> suffer. That's what I mean by "jarring".
This tells me something, although I'm not sure what exactly.
For me the process of reading prose and the process of reading
code are very different. I don't know that this will be
helpful but let me take a stab at defining (well, giving
analogies) for the different categories I mentioned.
(a) perceptual - like every other word is written in bold face
(b) cognitive - like verbs are in French rather than English
(c) familiar - like every third word is written right-to-left
(d) indirect - like triple spacing - no direct effect, but
having to turn pages three times as often slows
you down
(e) other - like tabs vs spaces - makes no difference to
reading, but does make a difference when editing
To try to ask the question in your frame, what is the "source"
of the jar force? (Based on what you say elsewhere my guess
is that it would be (c), but I don't want to assume that.)
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>
>>> First, 'if( ... )' looks too much like a function call; it's not,
>>> so I prefer 'if ( ... )'.
>>>
>>> Second, '( ... )' wastes space, and I prefer parentheses visually
>>> bound to what they're containing: '(...)'.
>>
>> Concerning adjacency, you say you prefer parentheses be visually
>> bound (to what's inside) but you don't say why. Can you explain
>> this beyond just saying it's what you prefer? In particular,
>> does putting spaces inside the parentheses make it harder for you
>> to read the result, or do you dislike it just because it's not
>> what you prefer?
>
> It's certainly what I'm used to, but it logically makes more sense
> to me for the container to be bound to what it's containing, just
> as there is no space between the milk jug and the milk. To have
> it bound to nothing makes no sense, but your example was even
> worse: the container was bound to the adjacent tokens _instead_!
This explains something. How you think of the parentheses is
different from how I think of them.
>> Speaking for myself, I find it natural to put
>> parentheses next to what's inside them when the whole is an
>> expansion from primary-expression, but generally not for other
>> places in the syntax where parentheses appear for just a part
>> of one right-hand-side. So for me the different kinds of roles
>> played in the syntax makes a difference for how I read them.
>
> Can you give examples?
Probably the easiest is the syntax rule for while() statements:
while ( Expression ) Statement
The parentheses here are part of the while() construct, not
especially related to Expression. In fact the left delimiter
is superfluous; it could be taken out with no problem at all.
The right delimiter is needed to avoid ambiguity about where
Expression ends and Statement begins - its purpose is really
more as a separator than an encloser. So I think of these
parentheses as "belonging" to the while() construct, not as
"enclosing" an expression.
>> Concerning similarity to function calls, how big do you think
>> the effect is here? Do you normally write function calls with
>> spaces inside the parentheses? That would seem to violate both
>> the conserve spaces principle and the adjacency principle. If
>> you don't usually put spaces inside function call parentheses,
>> then 'if( a == b )' doesn't look the same as a function call.
>> It seems like there's an inconsistency somewhere.
>
> I put spaces after commas in a list, including the list of
> arguments to a function call, and where they help with clarity.
>
> I find this objectionable:
>
> if(a)
>
> because it looks too much like this:
>
> fn(a)
>
> In the latter case, the container should be bound to the function
> name as well as its contents, whereas in the former case, it
> shouldn't be bound to the conditional:
>
> if (a)
>
> You may say that the conditional is just as logically bound to the
> condition as arguments are to a function, but there is some mental
> distinction that I can't put into words.
Okay, I acknowledge your view, and I understand that somtimes it
is hard to articulate what the underlying forces might be. Let
me try to respond in kind.
First, for functions, we might start with the syntax rule:
Postfix_expression ( Argument_expression_list )
Normally a Postfix_expression is a "little" expansion (most often
just an identifier), whereas Argument_expression_list is a "big"
expansion (by virtue of multiple arguments even when individual
arguments are simple). So it's natural for me to write a
function call like this:
foo( a, b )
because that corresponds to how I think of the syntax, and also
matches my thinking of where the "mental pauses" are. That is,
my thinking is something like (note that [PAUSE] is still pretty
short even though greater than zero):
foo of [PAUSE] a b [PAUSE]
and not
foo of a [PAUSE] b
which is how, subliminally, I would tend to read 'foo(a, b)'.
(In the first case there is no pause, or perhaps only a very
short pause, between a and b, because commas always have
spaces after them. But when there is no space between the
first three tokens that magnifies the pause after a comma,
or something like that.)
For if(), I don't find it confusing if they are written to be
similar lexically to function calls, although I'm not sure why;
maybe because 'if' is just a keyword I know, maybe because it
doesn't sound like the name of a function, maybe because it's
shorter than a typical function name, or maybe because the
context of what comes after the condition -- I just don't know.
So that aspect doesn't influence my reaction on this point.
Two other factors do. First, for 'if(a)' or 'if (a)', I feel
a subliminal urge -- probably learned from many years of reading
prose -- to *skip over* the stuff inside the parentheses. That's
the opposite of what I want to do here. A controlling condition,
like what is used in if() or while(), is DAMNED IMPORTANT and
should stick out physically so it sticks out mentally. To say
that another way, my desired mental process (assuming a test
that might be used to find the maximum of a set of values) is
if [LONG PAUSE] current > best [LONG PAUSE] ...
and so correspondingly I write if()'s (and I know you will hate
this, but oh well :) thusly (note multiple spaces):
if( current > best ) ...
The reason is I want to focus on the condition, and this way of
writing helps (or perhaps forces) me to do that.
>> Something that was snipped from a comment made upthread is my
>> rule to normally put two spaces inside (each of) the parentheses
>> that go with if(), while(), etc. Doing that makes if() etc
>> noticeably distinct compared to function calls. Introspecting a
>> bit, I also realize that the spaces correspond to a mental pause
>> that occurs (and I think there is a benefit that it does), when
>> reading an if() etc, to focus on the condition being tested.
>> This observation leads back to matters of spacing. For me, it's
>> important for the spacing used to correspond, at least roughly,
>> to how I chunkify the different parts of a line (and for vertical
>> spacing, of a function definition). Using varying amounts of
>> spacing in different circumstances - not just syntactically
>> different but also semantically different - is therefore a
>> major factor in what I write and what I find easy (or hard)
>> to read.
>>
>> Any reactions?
>
> Interesting, and you've obviously put a lot more thought into it
> than I have. I suppose your way makes sense, but I can't recall
> having ever seen code written that way, so perhaps it's jarring to
> me due to lack of familiarity--or perhaps it's an abomination like
> GNU style :)
Hopefully it's more the former than the latter, but I will leave
exploring that for another day.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-24 14:56 -0500 |
| Message-ID | <mjtaah$hh0$1@dont-email.me> |
| In reply to | #62354 |
On 20-May-15 11:29, Tim Rentsch wrote: > (Sorry btw for the longish delay in responding, it's just > how things are right now.) No worries; you're good about quoting relevant context, and threading makes it easy to figure out where we were (since I have at least a dozen different discussions going in various newsgroups), so I don't really notice the delays. >> I appreciate that you're trying to understand, but I'm not sure I >> even understand the distinctions you're trying to make; I can't >> really put it any better than "jarring". >> >> When I read a novel, my eyes scan very quickly and my brain is >> several seconds behind them. However, when my subconscious throws >> a parsing error, I'm forced to go back, locate the source of the >> problem, and re-parse it consciously, and then restart. Even >> something as minor as a misplaced comma can drop me from a few >> seconds per page to a few seconds _per sentence_, and if that >> happens too often, I usually toss the book rather than continue to >> suffer. That's what I mean by "jarring". > > This tells me something, although I'm not sure what exactly. For me > the process of reading prose and the process of reading code are very > different. For me, reading (well-written) code is similar to reading prose; it's only _writing_ code that is very different, but writing prose is rather different from reading it as well. > I don't know that this will be helpful but let me take a > stab at defining (well, giving analogies) for the different > categories I mentioned. > > (a) perceptual - like every other word is written in bold face I'm not sure I'd even notice that. > (b) cognitive - like verbs are in French rather than English I'm not sure I'd notice that either; I deal with mixed Spanish and English (aka Spanglish) all the time in the real world, and I know enough French that it'd probably be the same, though I can't say I've ever seen or heard it before in practice. (I speak all three.) > (c) familiar - like every third word is written right-to-left That'd probably be jarring, since I don't know any RTL languages. OTOH, I can read both AT&T (op src, dst) and Intel (op dst, src) style x86 assembly without much difficulty, so maybe not. > (d) indirect - like triple spacing - no direct effect, but having to > turn pages three times as often slows you down That'd be annoying, but I don't think it'd be jarring. > (e) other - like tabs vs spaces - makes no difference to reading, > but does make a difference when editing As you say, that wouldn't affect reading. > To try to ask the question in your frame, what is the "source" of the > jar force? (Based on what you say elsewhere my guess is that it > would be (c), but I don't want to assume that.) That's my best guess, but I'm not sure I know for sure. I'm sorry I can't be more helpful here. >> It's certainly what I'm used to, but it logically makes more sense >> to me for the container to be bound to what it's containing, just >> as there is no space between the milk jug and the milk. To have it >> bound to nothing makes no sense, but your example was even worse: >> the container was bound to the adjacent tokens _instead_! > > This explains something. How you think of the parentheses is > different from how I think of them. > ... > Probably the easiest is the syntax rule for while() statements: > > while ( Expression ) Statement > > The parentheses here are part of the while() construct, not > especially related to Expression. ... So I think of these > parentheses as "belonging" to the while() construct, not as > "enclosing" an expression. Ah, this is the root of our disagreement. My mental model is "while Expression Statement", with Expression being restricted to the subset of expressions enclosed in parentheses. Ditto for if statements. I'm not sure how I square this with for's syntax, since the parentheses obviously don't enclose a normal expression but rather three separate expressions separated by semicolons. Maybe the fact those three expressions are (in a way) executed in sequence, like any other set of expressions separated by semicolons, mitigates that oddity? > foo( a, b ) > > because that corresponds to how I think of the syntax, and also > matches my thinking of where the "mental pauses" are. That is, my > thinking is something like (note that [PAUSE] is still pretty short > even though greater than zero): > > foo of [PAUSE] a b [PAUSE] > > and not > > foo of a [PAUSE] b > > which is how, subliminally, I would tend to read 'foo(a, b)'. (In the > first case there is no pause, or perhaps only a very short pause, > between a and b, because commas always have spaces after them. But > when there is no space between the first three tokens that magnifies > the pause after a comma, or something like that.) When used as a list separator, I read a comma as "and": foo(a, b) -> foo of a and b Incidentally, this is the same reason I dislike Oxford commas; a list comma already means "and", and writing "and and" makes no sense. Without the space after the comma, though, the comma becomes only a visual separator: foo(a,b) -> foo of ab > Two other factors do. First, for 'if(a)' or 'if (a)', I feel a > subliminal urge -- probably learned from many years of reading prose > -- to *skip over* the stuff inside the parentheses. Ah, that may be another major difference. When I'm reading prose, a parenthetical clause comes out in a different (usually lower) voice, like an aside in a stage play, and my brain saves the state of the main voice until it returns. I don't "skip over" them, since if it weren't worth reading, presumably it wouldn't be there in the first place. But my brain does throw a parsing error with multiple levels; apparently it can only keep track of two voices in the fast path. FWIW, I also tend to get confused in live conversations between more than three people, which is an interesting (and frustrating) social impairment. The same mechanism may be at play when reading code; past two levels of nested parentheses, I have to switch to conscious parsing, which is very slow, rather than subconscious parsing, which is very fast. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 08:30 -0700 |
| Message-ID | <kfnmvz46ndp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62541 |
Stephen Sprunk <stephen@sprunk.org> writes: > On 20-May-15 11:29, Tim Rentsch wrote: >> (Sorry btw for the longish delay in responding, it's just >> how things are right now.) > > No worries; you're good about quoting relevant context, and threading > makes it easy to figure out where we were (since I have at least a dozen > different discussions going in various newsgroups), so I don't really > notice the delays. Thank you for the positive comment. >>> I appreciate that you're trying to understand, but I'm not sure I >>> even understand the distinctions you're trying to make; I can't >>> really put it any better than "jarring". >>> >>> When I read a novel, my eyes scan very quickly and my brain is >>> several seconds behind them. However, when my subconscious throws >>> a parsing error, I'm forced to go back, locate the source of the >>> problem, and re-parse it consciously, and then restart. Even >>> something as minor as a misplaced comma can drop me from a few >>> seconds per page to a few seconds _per sentence_, and if that >>> happens too often, I usually toss the book rather than continue to >>> suffer. That's what I mean by "jarring". >> >> This tells me something, although I'm not sure what exactly. For me >> the process of reading prose and the process of reading code are very >> different. > > For me, reading (well-written) code is similar to reading prose; That surprises me. How I read code is very unlike how I read prose. > it's > only _writing_ code that is very different, but writing prose is rather > different from reading it as well. Roger that! >> I don't know that this will be helpful but let me take a >> stab at defining (well, giving analogies) for the different >> categories I mentioned. >> >> (a) perceptual - like every other word is written in bold face > > I'm not sure I'd even notice that. > >> (b) cognitive - like verbs are in French rather than English > > I'm not sure I'd notice that either; I deal with mixed Spanish and > English (aka Spanglish) all the time in the real world, and I know > enough French that it'd probably be the same, though I can't say I've > ever seen or heard it before in practice. (I speak all three.) > >> (c) familiar - like every third word is written right-to-left > > That'd probably be jarring, since I don't know any RTL languages. > > OTOH, I can read both AT&T (op src, dst) and Intel (op dst, src) style > x86 assembly without much difficulty, so maybe not. > >> (d) indirect - like triple spacing - no direct effect, but having to >> turn pages three times as often slows you down > > That'd be annoying, but I don't think it'd be jarring. > >> (e) other - like tabs vs spaces - makes no difference to reading, >> but does make a difference when editing > > As you say, that wouldn't affect reading. I appreciate the responses, but what I was hoping for was a more substantial response to my upthread question after the categories were explained. Oh well, maybe another time. >> To try to ask the question in your frame, what is the "source" of the >> jar force? (Based on what you say elsewhere my guess is that it >> would be (c), but I don't want to assume that.) > > That's my best guess, but I'm not sure I know for sure. I'm sorry I > can't be more helpful here. Let me ask you (very gently) to try to notice when you read code later and see if something jumps out at you. >>> It's certainly what I'm used to, but it logically makes more sense >>> to me for the container to be bound to what it's containing, just >>> as there is no space between the milk jug and the milk. To have it >>> bound to nothing makes no sense, but your example was even worse: >>> the container was bound to the adjacent tokens _instead_! >> >> This explains something. How you think of the parentheses is >> different from how I think of them. >> ... >> Probably the easiest is the syntax rule for while() statements: >> >> while ( Expression ) Statement >> >> The parentheses here are part of the while() construct, not >> especially related to Expression. ... So I think of these >> parentheses as "belonging" to the while() construct, not as >> "enclosing" an expression. > > Ah, this is the root of our disagreement. I would say rather that this is the root of our differing perceptions. I'm not trying to argue either one is better than the other, only to understand the source of the differences. > My mental model is "while Expression Statement", with Expression being > restricted to the subset of expressions enclosed in parentheses. > > Ditto for if statements. I think most C developers have that model. I don't do that, because I want my mental model to match the actual syntax rules. > I'm not sure how I square this with for's syntax, since the parentheses > obviously don't enclose a normal expression but rather three separate > expressions separated by semicolons. Maybe the fact those three > expressions are (in a way) executed in sequence, like any other set of > expressions separated by semicolons, mitigates that oddity? It sounds like you put a higher value on lexical similarity than semantic fidelity. It's hard for me to imagine thinking of the the clauses in a for() in the way that you describe. >> foo( a, b ) >> >> because that corresponds to how I think of the syntax, and also >> matches my thinking of where the "mental pauses" are. That is, my >> thinking is something like (note that [PAUSE] is still pretty short >> even though greater than zero): >> >> foo of [PAUSE] a b [PAUSE] >> >> and not >> >> foo of a [PAUSE] b >> >> which is how, subliminally, I would tend to read 'foo(a, b)'. (In the >> first case there is no pause, or perhaps only a very short pause, >> between a and b, because commas always have spaces after them. But >> when there is no space between the first three tokens that magnifies >> the pause after a comma, or something like that.) > > When used as a list separator, I read a comma as "and": > > foo(a, b) -> foo of a and b In code, I read list-separator commas either as a short pause or as "comma". Reading prose, I think I read list-separator commas usually as a short pause, but may voice them as "comma" when it is important to be unambiguous. > Incidentally, this is the same reason I dislike Oxford commas; a list > comma already means "and", and writing "and and" makes no sense. I find Oxford commas seem appropriate in some cases, and not appropriate in others. I don't think either choice is best in all cases. btw, you might be interested to know there was a case involving a legal document where the outcome depended on the omission of an Oxford comma. > Without the space after the comma, though, the comma becomes only a > visual separator: > > foo(a,b) -> foo of ab Hmmm. I still want to read them as a short pause, which may account for my practice of always using spaces in such cases. >> Two other factors do. First, for 'if(a)' or 'if (a)', I feel a >> subliminal urge -- probably learned from many years of reading prose >> -- to *skip over* the stuff inside the parentheses. > > Ah, that may be another major difference. When I'm reading prose, a > parenthetical clause comes out in a different (usually lower) voice, > like an aside in a stage play, and my brain saves the state of the main > voice until it returns. I don't "skip over" them, since if it weren't > worth reading, presumably it wouldn't be there in the first place. I should clarify my previous statement. I don't actually skip over the parenthesized stuff, just, hmm, something, give it less weight maybe. So my process is similar to yours, except I might add that subliminally I feel a "this is not really important to pay attention to" overtone, which you might not. > But > my brain does throw a parsing error with multiple levels; apparently it > can only keep track of two voices in the fast path. FWIW, I also tend > to get confused in live conversations between more than three people, > which is an interesting (and frustrating) social impairment. I find it hard to process conversation when there is more than one person speaking at once, however many people there are. But I think that's an auditory effect, not a cognitive one. > The same mechanism may be at play when reading code; past two levels of > nested parentheses, I have to switch to conscious parsing, which is very > slow, rather than subconscious parsing, which is very fast. I think for me it depends a lot on the kind of expressions involved. If the different levels "stratify" nicely then then handling even four or five levels is not so bad; for the general case though three levels (which corresponds to two levels of parentheses) is normally the limit. Also I would say the depth of nesting is what matters, not affected so much by whether parentheses are needed to produce the nesting.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 11:04 -0700 |
| Message-ID | <lnr3of7uuh.fsf@kst-u.example.com> |
| In reply to | #65118 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Stephen Sprunk <stephen@sprunk.org> writes:
[...]
>> My mental model is "while Expression Statement", with Expression being
>> restricted to the subset of expressions enclosed in parentheses.
>>
>> Ditto for if statements.
>
> I think most C developers have that model. I don't do that,
> because I want my mental model to match the actual syntax rules.
I'd be a bit surprised if most C developers have that model, though I
have no particular basis for that. I certainly don't think of it that
way. In
if (expression)
I *don't* think of `(expression)` as a parenthesized expression.
I think of the parentheses as part of the syntax of the if statement.
Of course I am not "most C developers".
Perhaps it's influenced by the fact that I've used languages that
don't use parentheses in that context; for example Ada has:
if expression then
...
end if;
(In fact I prefer that approach.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-07-10 18:39 -0500 |
| Message-ID | <mnpl0m$dlp$1@dont-email.me> |
| In reply to | #65157 |
On 10-Jul-15 13:04, Keith Thompson wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Stephen Sprunk <stephen@sprunk.org> writes: > [...] >>> My mental model is "while Expression Statement", with Expression >>> being restricted to the subset of expressions enclosed in >>> parentheses. >>> >>> Ditto for if statements. >> >> I think most C developers have that model. I don't do that, >> because I want my mental model to match the actual syntax rules. > > I'd be a bit surprised if most C developers have that model, though > I have no particular basis for that. I certainly don't think of it > that way. In > > if (expression) > > I *don't* think of `(expression)` as a parenthesized expression. I > think of the parentheses as part of the syntax of the if statement. > > Of course I am not "most C developers". > > Perhaps it's influenced by the fact that I've used languages that > don't use parentheses in that context; for example Ada has: > > if expression then > ... > end if; That is _why_ I see the parentheses as part of the expression: the first several languages I learned didn't require them. When I learned C, I learned that these two expressions are equivalent: a < b (a < b) except in the context of an if (or while) statement, where the latter form must always be used. I know consciously this is a defect in my subconscious parsing, at least according to the Standard, but it doesn't matter in practice; nobody would have ever known if it weren't for the subtle differences exposed in this thread. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-10 17:02 -0700 |
| Message-ID | <0732ecd7-ce43-47c6-a56f-7bce91b1d71e@googlegroups.com> |
| In reply to | #65199 |
On Saturday, July 11, 2015 at 12:56:39 AM UTC+1, Stefan Ram wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
> >On 10-Jul-15 13:04, Keith Thompson wrote:
> >>if (expression)
> >>if expression then
> >That is _why_ I see the parentheses as part of the expression: the first
> >several languages I learned didn't require them. When I learned C, I
> >learned that these two expressions are equivalent:
> >a < b
> >(a < b)
> >except in the context of an if (or while) statement, where the latter
> >form must always be used.
>
> Then you learned something that is false in C.
>
> >I know consciously this is a defect in my subconscious parsing, at least
>
> Ok, so you already are aware that it is false in C.
>
> >according to the Standard, but it doesn't matter in practice; nobody
>
> It matters for me in my practice as I teach C and give
> diagrams such as
>
> Syntax of the conditional statement
> .''. .''. .------------. .''. .-----------.
> --->( if )--->( ( )--->| expression |--->( ) )--->| statement |--->
> '..' '..' '------------' '..' '-----------'
>
> at the very beginning of the lesson about »if«. I have
> explained such diagrams before and would not want to mislead
> students by a false grammar that is not compatible with the
> standard literature.
>
> I would not hesitate to use little lies in teaching when I see
> that they make learning much easier, but in this case, I do not
> see an advantage of omitting the parentheses in the diagram.
>
The way to teach if is
if(a < b)
{
printf("%d is less that %d\n" a, b);
}
else
{
printf("%d is not less than %d\n", a, b);
}
anyone with any aptitude for programming whatsoever will get the idea
instantly. Worry about the formal grammar when you come to write
a compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-11 01:23 +0100 |
| Message-ID | <mnpnkb$k8c$1@dont-email.me> |
| In reply to | #65201 |
On 11/07/2015 01:02, Malcolm McLean wrote: > anyone with any aptitude for programming whatsoever will get the idea > instantly. Worry about the formal grammar when you come to write > a compiler. And sometimes not even then!
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-10 17:48 -0700 |
| Message-ID | <9b8b0043-1a3e-48ac-ae34-7af8a97c455b@googlegroups.com> |
| In reply to | #65201 |
On Saturday, July 11, 2015 at 1:29:25 AM UTC+1, Stefan Ram wrote: > > When I teach »if« after having taught »?:«, I want > to show something that can be done much better with > »if« than with »?:«, something where »if« really shines! > That's a weird strategy. Most programming languages have an if. It's completely intuitive. If some condition holds, do something. The ?: syntax was really introduced to make macros easier to write, but it can be more readable, in relatively advanced code that's gone beyond the teaching language stage and has long functions with lots of trivial jumps. It's not all obvious what it should mean to someone coming to C, even from a programming background, it can always be rewritten in terms of if, and it obscures the fact that it's a flow control statement.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-11 10:50 +0100 |
| Message-ID | <87h9pbuioh.fsf@bsb.me.uk> |
| In reply to | #65212 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 11, 2015 at 1:29:25 AM UTC+1, Stefan Ram wrote: >> >> When I teach »if« after having taught »?:«, I want >> to show something that can be done much better with >> »if« than with »?:«, something where »if« really shines! >> > That's a weird strategy. <snip> > The ?: syntax was really introduced to make macros easier to write, Do you have any evidence for that odd claim? All of the often-cited influences on C (BCPL (and hence CPL), B and Algol 68) had such an operator and none had macros. The C reference manual uses ?: but not in a macro. The evidence (such as it is) points to it's being introduced because it's useful (as indeed it is). > but it can be more readable, in relatively advanced code that's > gone beyond the teaching language stage and has long functions with > lots of trivial jumps. I don't consider an expression whose value depends on a condition to be either advanced or "beyond teaching the language". It's a natural expression form that occurs in mathematics and predates programming by a long chalk. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 06:55 -0700 |
| Message-ID | <b68145c6-ec18-4c20-84c1-9fa5564e9a81@googlegroups.com> |
| In reply to | #65243 |
On Saturday, July 11, 2015 at 10:50:46 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > > The ?: syntax was really introduced to make macros easier to write, > > Do you have any evidence for that odd claim? All of the often-cited > influences on C (BCPL (and hence CPL), B and Algol 68) had such an > operator and none had macros. The C reference manual uses ?: but not in > a macro. The evidence (such as it is) points to it's being introduced > because it's useful (as indeed it is). > I might be wrong about that. A function-like macro often need to return a value based on a condition. Since it can't use the return keyword, ? : syntax is the only way of making the macro look like a function call. > > > but it can be more readable, in relatively advanced code that's > > gone beyond the teaching language stage and has long functions with > > lots of trivial jumps. > > I don't consider an expression whose value depends on a condition to be > either advanced or "beyond teaching the language". It's a natural > expression form that occurs in mathematics and predates programming by a > long chalk. > It's a functional programming construct. To say it has no place in a procedural language is over-doing it, you can use little bits of other paradigms in basically procedural code without harming it. But flow control should look like flow control. It can also neaten up long functions with trivial ifs. Generally this is sign that the source is getting out of hand, but not always.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-11 15:23 +0100 |
| Message-ID | <87y4imu62f.fsf@bsb.me.uk> |
| In reply to | #65262 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 11, 2015 at 10:50:46 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> >> > The ?: syntax was really introduced to make macros easier to write, >> >> Do you have any evidence for that odd claim? All of the often-cited >> influences on C (BCPL (and hence CPL), B and Algol 68) had such an >> operator and none had macros. The C reference manual uses ?: but not in >> a macro. The evidence (such as it is) points to it's being introduced >> because it's useful (as indeed it is). >> > I might be wrong about that. > A function-like macro often need to return a value based on a > condition. Since it can't use the return keyword, ? : syntax is > the only way of making the macro look like a function call. They are, of course, useful in macros as are all the operators. >> > but it can be more readable, in relatively advanced code that's >> > gone beyond the teaching language stage and has long functions with >> > lots of trivial jumps. >> >> I don't consider an expression whose value depends on a condition to be >> either advanced or "beyond teaching the language". It's a natural >> expression form that occurs in mathematics and predates programming by a >> long chalk. >> > It's a functional programming construct. It's just another expression form. > To say it has no place > in a procedural language is over-doing it, you can use little bits > of other paradigms in basically procedural code without harming it. > But flow control should look like flow control. Another aphorism that raises so many questions. What is flow control? Why do you think a ? b : c does not look like flow control? And if it does not look like it why should it? Do you avoid a || b and a && b, and if so, to what length will you go to make the flow control look like flow control. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 08:14 -0700 |
| Message-ID | <81daba02-badf-40eb-8a57-969d083283d4@googlegroups.com> |
| In reply to | #65268 |
On Saturday, July 11, 2015 at 3:23:12 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> Another aphorism that raises so many questions. What is flow control?
> Why do you think a ? b : c does not look like flow control? And if it
> does not look like it why should it? Do you avoid a || b and a && b,
> and if so, to what length will you go to make the flow control look like
> flow control.
>
I tend to avoid intelligent OR and AND guarding unless it's obvious
that the first argument is intended as a guard.
If we've got this
if( (title == HERMAJESTY) || sayuptherepublic() )
{
assert(headon);
talk();
}
it's not entirely obvious that the assertion is going to fail if
we switch the order of the OR in the condition.
So I don't like it. It's risky.
On the other hand if you've got
if(ptr && *ptr == x)
then it's pretty clear that the first condition is meant as a guard.
I prefer
if(ptr)
{
if(*ptr == x)
}
but that can introduce too many levels of nesting.
If it's simply
if( a==b || a + b < c)
then of course it doesn't matter whether code is executed to evaluate
a+b < c or not, so unless we're counting every cycle, we don't worry
about it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 07:53 -0700 |
| Message-ID | <1e691dfe-bad7-49f3-848c-c8e7600c3d2c@googlegroups.com> |
| In reply to | #65262 |
On Saturday, July 11, 2015 at 3:15:18 PM UTC+1, Stefan Ram wrote: > > When one is writing > > printf( "%g\n", 4 * atan( 1 )); > > , one also is using »functional-programming constructs«: > The function term »atan( 1 )« and the multiplication operator. > > A purely imperative program would be > > LDA #1 > JSR ATAN > LDX #4 > MUL > LDX .G > JSR PRINTF > > . Yes, and a little bit of nesting is harmless, but it rapidly becomes unreadable if we pass several function calls to each other. The imperative code becomes a lot more readable if you use a slightly high-level language create buffer of 8 bytes called x; call atan with tangent = 1.0, theta = x; call fmultiply with a = 4, b = x, result = x call printf with format = "%g\n", args = x It's quite common to abandon function return values in C libraries, reserving the return value for an error condition flag. However the convention of writing a few basic maths functions as functions which can be embedded in expressions is so well established that it's silly to try to override it for a theoretical harmony. And basic arithmetical expressions themselves must be written as conventional infix expressions, not trees (as anyone who has tried to program Lisp soon realises), or as imperative calls (as anyone who has tried to use a bignum library soon realises).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-11 22:04 +0100 |
| Message-ID | <87a8v2tngv.fsf@bsb.me.uk> |
| In reply to | #65262 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>A function-like macro often need to return a value based on a
>>condition. Since it can't use the return keyword, ? : syntax is
>>the only way of making the macro look like a function call.
>
> It is true that »if« cannot be used in an expression.
>
> However, if one would really care for macros, it would
> be more general to introduce the block return as in:
>
> double const pi ={ double x = atan( 1 ); x *= 4; return x; };
As you may know, one of C's grandparents (BCPL) had this construct.
Function bodies where just expressions, many of which where blocks that
returned. And Algol 68 (another ancestor) made little distinction
between what C calls expressions and statements. Just as in C a
procedure call is a function call whose value you ignore, in Algol 68 an
IF clause is just a conditional expression whose value you ignore.
It seems odd to me that this generality of design should have been
thrown away. Why can't I declare a variable in the condition of an if?
Why can't I initialise a variable with the result of a calculation that
involves, for example, a while loop? These features would probably be
used rarely, but omitting them complicates the language, at least from
an intellectual point of view.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 14:51 -0700 |
| Message-ID | <eb1df141-d7c0-4236-a3e0-e3d506ca8c71@googlegroups.com> |
| In reply to | #65341 |
On Saturday, July 11, 2015 at 10:05:04 PM UTC+1, Ben Bacarisse wrote: > > As you may know, one of C's grandparents (BCPL) had this construct. > Function bodies where just expressions, many of which where blocks that > returned. And Algol 68 (another ancestor) made little distinction > between what C calls expressions and statements. Just as in C a > procedure call is a function call whose value you ignore, in Algol 68 an > IF clause is just a conditional expression whose value you ignore. > > It seems odd to me that this generality of design should have been > thrown away. Why can't I declare a variable in the condition of an if? > Why can't I initialise a variable with the result of a calculation that > involves, for example, a while loop? These features would probably be > used rarely, but omitting them complicates the language, at least from > an intellectual point of view. > It's the mismatch between something that makes theoretical sense and something that human programmers actually want to use. Lisp's tree syntax for arithmetical expressions makes perfect sense, and BODMAS does not 4 - 2 + 1 should be 1, not 3, and 2 * -3 is another difficulty. And in reality, if you see 100 + 10 * 2 in many contexts, you need to check the logic to see what is intended. But trying to express formulae using the tree system is hopeless, maybe if you'd been taught it a primary school it would feel natural, but nobody is taught arithmetic with that notation.
[toc] | [prev] | [next] | [standalone]
Page 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web