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 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-11 09:37 -0700 |
| Message-ID | <176a4a2f-cd66-4090-a91d-a1fda9d38f6b@googlegroups.com> |
| In reply to | #61843 |
On Monday, May 11, 2015 at 9:20:33 AM UTC-7, Tim Rentsch wrote:
>
> 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)
>
> 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?
As asked (c). But
I would find
printf("foo[%2d] is %9.2f\n",i,foo[i]);
easier than either. The extra spaces are there for format reasons
but they do not help the output and jar in the code.
I think you have to take into account the font the text is being displayed
in. A monospaced font will look different than a variable-width font. And
I suspect that within either class one will find fonts that give different
appearances. Even in a printf you can't be sure what the print format will
be.
Personally I code in a variable-width font.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-11 09:40 -0700 |
| Message-ID | <8a00c6b9-9adc-4396-a9cf-047c625de2e8@googlegroups.com> |
| In reply to | #61843 |
On Monday, May 11, 2015 at 9:20:33 AM UTC-7, 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): > > (a) Compactness is much more important than visual openness; > > (b) Compactness deserves a weight between 1x and 2x that of > visual openness; > > (c) Compactness and visual openness are equally important; > > (d) Visual openness deserves a weight between 1x and 2x that > of compactness; or > > (e) Visual openness is much more important than compactness. > > Note that compactness and openness are not necessarily mutually > exclusive, because in most cases there is free space at the end > of lines after declaration or statement breaks. Assuming I understand your terms correctly I vote for (a). I expect that is a minority position.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-11 09:46 -0700 |
| Message-ID | <74e37f43-4bae-4c42-a93a-ba4f401e2822@googlegroups.com> |
| In reply to | #61843 |
On Monday, May 11, 2015 at 9:20:33 AM UTC-7, Tim Rentsch wrote:
> 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?
>
> 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. Asking just about conserving space, which of
> the following most closely matches your view?
>
> (a) Conserving spaces has a strong and direct effect on ease
> of reading;
>
> (b) Conserving spaces has a moderate direct effect on ease
> of reading, but also is important for other reasons;
>
> (c) Conserving spaces sometimes has a direct effect on ease
> of reading but also has indirect effects that contribute
> to that (and are significant);
>
> (d) Conserving spaces primarily has an indirect benefit on
> ease of reading; or
>
> (e) Conserving spaces is important only for larger scale
> considerations (notably, length of function bodies)
> that affect "readability in the large", but does not
> affect ease of reading locally.
>
> Of course please feel free to make up your own answer if none of
> the above adequately represents your view.
My position would be that
Conserving space per se should not be considered. Space should be
left where it is needed or automatic (like ends of lines) and not
consider otherwise.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-11 09:53 -0700 |
| Message-ID | <88e11be0-dce1-41c1-8eb2-3a782110d9fe@googlegroups.com> |
| In reply to | #61843 |
On Monday, May 11, 2015 at 9:20:33 AM UTC-7, Tim Rentsch wrote:
>
> 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). However I think the
> considerations for horizontal spacing and for vertical spacing
> are not exactly the same, because of the asymmetry between the
> two dimensions in code writing. (Compare for example to prose
> writing.) In particular I am often interested in how many lines
> are used (eg, by a function definition), but only rarely about
> how wide a line is, because most lines end naturally before their
> hard limit (nominally 79 columns). 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? I'm just curious. Also, related to that,
> how much indentation per nesting level are you accustomed to (a
> multi-valued answer definitely possible here)? And now finally
> the question about vertical space: 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%:
>
> (a) 0%
> (b) 5%
> (c) 10%
> (d) 15%
> (e) 20%
> (f) 25+%
In, for example, GTK+ logical lines are often very long because names are
often very long. There is a reason for the long names which might merit
some discussion.
I wouldn't use percentage to measure that space. I would use one blank
line - I leave no blank lines within a function (I pseudo a blank line
with a small comment ("//" or "/**/")
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-11 13:47 -0500 |
| Message-ID | <miqte3$735$1@dont-email.me> |
| In reply to | #61843 |
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.
> 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.
> 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.
> 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.
> 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. 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.
Note that I prefer my monitors in portrait mode (tall and narrow), which
is the opposite of most users and traditional terminals.
> 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.
> 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.
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-11 20:04 +0100 |
| Message-ID | <miqueo$bsr$1@dont-email.me> |
| In reply to | #61851 |
On 11/05/15 19:47, Stephen Sprunk wrote:
> On 11-May-15 11:20, Tim Rentsch wrote:
<snip>
>> 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 :)
Yes, it's rather like UK legislation - you get rid of the difficult bit
in the title, where it does less harm.
All right, let's just say my curiosity has finally got the better of me.
In the following:
int foo(parms)
{
first indent level;
if(more)
{
second indent level;
}
return bar;
}
the braces and indents work together to make the depth of the code very,
very clear. This one works for me, because it looks clear.
What looks rather less clear to me is 1TBS, which I understand to be:
int foo(parms) {
first indent level;
if(more) {
second indent level;
}
return bar;
}
What I'm curious about is this: what advantage do you see in this, that
compensates for the loss of visual reinforcement of the code structure
that Allman style (top) provides?
The *only* argument in favour of 1TBS I have heard to date is that it
conserves vertical space, which is very much akin to conserving carbon
dioxide (i.e. yes, vertical space certainly has its uses, but we'll
always have more than we can possibly use and if ever we're short of it
we can always make some more, as easy as breathing).
Does anyone have some other reason for preferring 1TBS?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-11 12:39 -0700 |
| Message-ID | <87wq0egazg.fsf@kst-u.example.com> |
| In reply to | #61856 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> All right, let's just say my curiosity has finally got the better of me.
>
> In the following:
>
> int foo(parms)
> {
> first indent level;
> if(more)
> {
> second indent level;
> }
> return bar;
> }
>
> the braces and indents work together to make the depth of the code
> very, very clear. This one works for me, because it looks clear.
>
> What looks rather less clear to me is 1TBS, which I understand to be:
>
> int foo(parms) {
> first indent level;
> if(more) {
> second indent level;
> }
> return bar;
> }
>
> What I'm curious about is this: what advantage do you see in this,
> that compensates for the loss of visual reinforcement of the code
> structure that Allman style (top) provides?
Personally, I don't agree that there's a loss of visual
reinforcement.
For me, the structure of the code is clear from the indentation.
The closing "}" is directly under the first character of the "if",
with nothing but whitespace between them. Adding a "{" along that
vertical line doesn't make the structure any clearer, and in fact
it very slightly detracts from it (for me).
The saving in vertical space is minor, but the cost is insignificant.
The purpose of putting the "}" at the end of the line is mostly to
get it out of the way, so it's less of a distraction.
I suppose there's a sense in which matching an opening "{" with a
closing "}" along a vertical line is simpler than matching one of
several opening keywords with a closing "}", but I don't find that
to be a significant advantage.
[...]
--
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 | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2015-05-12 07:34 +0000 |
| Message-ID | <slrnml3b7r.2hk.nw@granicus.if.org> |
| In reply to | #61857 |
On 2015-05-11, Keith Thompson <kst-u@mib.org> wrote:
> I suppose there's a sense in which matching an opening "{" with a
> closing "}" along a vertical line is simpler than matching one of
> several opening keywords with a closing "}", but I don't find that
> to be a significant advantage.
And indeed, I find being able to visually trace up the screen to the
opening keyword to be useful, at least if the block fits on one screen.
If I hit a brace, then I still need to go up one more line to find
the keyword. Which is silly, I already know there's an opening brace,
what I don't know is what the conditional (or what-have-you) is.
--
nw
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-05-12 10:58 +0000 |
| Message-ID | <5551dc07.632593@news.xs4all.nl> |
| In reply to | #61857 |
Keith Thompson <kst-u@mib.org> wrote:
> I suppose there's a sense in which matching an opening "{" with a
> closing "}" along a vertical line is simpler than matching one of
> several opening keywords with a closing "}", but I don't find that
> to be a significant advantage.
Neither do I, particularly since it is already of interest _which_
keyword this brace closes. IOW, in
if (condition) {
...code...
}
you already want to know whether that's an if or a while loop.
IOOW, in
if (condition)
{
...code...
}
you rarely scan up to the { _and then stop_. You go on to the if anyway.
It's the if that is more significant, not the {. Therefore, I agree,
there is no real advantage to me to have the { on its own line.
(All this, of course, as long as the indentation is correct. But that is
important in Allman style just as much as in K&R - or any other, FTM.)
Richard
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-11 21:00 +0100 |
| Message-ID | <mir1mk$q01$1@dont-email.me> |
| In reply to | #61856 |
On 11/05/2015 20:04, Richard Heathfield wrote:
> On 11/05/15 19:47, Stephen Sprunk wrote:
>> Well, it's called 1TBS for a reason :)
> In the following:
>
> int foo(parms)
> {
> first indent level;
> if(more)
> {
> second indent level;
> }
> return bar;
> }
That's too spread out, especially with the extra line between the 'if'
and the statements in the True branch.
> the braces and indents work together to make the depth of the code very,
> very clear. This one works for me, because it looks clear.
>
> What looks rather less clear to me is 1TBS, which I understand to be:
>
> int foo(parms) {
> first indent level;
> if(more) {
> second indent level;
> }
> return bar;
> }
>
> What I'm curious about is this: what advantage do you see in this, that
> compensates for the loss of visual reinforcement of the code structure
> that Allman style (top) provides?
>
> The *only* argument in favour of 1TBS I have heard to date is that it
> conserves vertical space, which is very much akin to conserving carbon
> dioxide (i.e. yes, vertical space certainly has its uses, but we'll
> always have more than we can possibly use and if ever we're short of it
> we can always make some more, as easy as breathing).
>
> Does anyone have some other reason for preferring 1TBS?
It matches the typical style of languages using if-then-else-end if:
if more then
second indent level
end if
With a more elaborate if:
if cond1 then
stmts1
elsif cond2 then
stmts2
else
stmts3
end if
The block structure is very clear. The 'then' ({) also obviously belongs
on the same line as the if or else, and each 'end' (}) obviously should
be in line with the corresponding if or else.
With { and }, no single placement style is obvious right (and you also
get single statements when no braces are needed, yet another visual style.).
With your preferred brace style, there will be lots of extraneous
vertical space introduced, depending on whether your 'else's follow on
on the same line as the "}".
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-11 21:18 +0100 |
| Message-ID | <mir2om$ujd$1@dont-email.me> |
| In reply to | #61858 |
On 11/05/15 21:00, Bartc wrote:
> On 11/05/2015 20:04, Richard Heathfield wrote:
>> On 11/05/15 19:47, Stephen Sprunk wrote:
>
>>> Well, it's called 1TBS for a reason :)
>
>> In the following:
>>
>> int foo(parms)
>> {
>> first indent level;
>> if(more)
>> {
>> second indent level;
>> }
>> return bar;
>> }
>
> That's too spread out, especially with the extra line between the 'if'
> and the statements in the True branch.
>
>> the braces and indents work together to make the depth of the code very,
>> very clear. This one works for me, because it looks clear.
>>
>> What looks rather less clear to me is 1TBS, which I understand to be:
>>
>> int foo(parms) {
>> first indent level;
>> if(more) {
>> second indent level;
>> }
>> return bar;
>> }
>>
>> What I'm curious about is this: what advantage do you see in this, that
>> compensates for the loss of visual reinforcement of the code structure
>> that Allman style (top) provides?
>>
>> The *only* argument in favour of 1TBS I have heard to date is that it
>> conserves vertical space, which is very much akin to conserving carbon
>> dioxide (i.e. yes, vertical space certainly has its uses, but we'll
>> always have more than we can possibly use and if ever we're short of it
>> we can always make some more, as easy as breathing).
>>
>> Does anyone have some other reason for preferring 1TBS?
>
> It matches the typical style of languages using if-then-else-end if:
>
> if more then
> second indent level
> end if
That may well be true, but it's of no consequence. It's as if I had
asked why some people like to drive Porsches at 4mph and were to be
given the reply "it matches the typical speed at which people walk".
Even if it's true, it's hardly an answer.
>
> With a more elaborate if:
>
> if cond1 then
> stmts1
> elsif cond2 then
> stmts2
> else
> stmts3
> end if
>
> The block structure is very clear.
In abbreviated form, yes. When the blocks are much larger, it is (in my
view) less clear than Allman.
> The 'then' ({) also obviously belongs
> on the same line as the if or else, and each 'end' (}) obviously should
> be in line with the corresponding if or else.
Whenever I see the word "obviously" I get suspicious, and I'm suspicious
now. *Why* is it obvious? (And in fact it isn't obvious to me.)
> With { and }, no single placement style is obvious right (and you also
> get single statements when no braces are needed, yet another visual style.).
<shrug> I tend to use the braces anyway. It's easier to add them now
than it is to puzzle out a bug later because I forgot to add them during
a mod.
> With your preferred brace style, there will be lots of extraneous
> vertical space introduced, depending on whether your 'else's follow on
> on the same line as the "}".
Clearly you see the "extraneous" vertical space as a disadvantage. I see
it as an advantage. It has the same visual benefit as an empty line (and
that visual benefit is very real, which is why Usenauts put a blank line
between paragraphs), but with the added benefit that it's not empty. :-)
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-11 23:37 +0100 |
| Message-ID | <mirau0$11t$1@dont-email.me> |
| In reply to | #61859 |
On 11/05/2015 21:18, Richard Heathfield wrote:
> On 11/05/15 21:00, Bartc wrote:
>> On 11/05/2015 20:04, Richard Heathfield wrote:
>>> Does anyone have some other reason for preferring 1TBS?
>>
>> It matches the typical style of languages using if-then-else-end if:
>>
>> if more then
>> second indent level
>> end if
>
> That may well be true, but it's of no consequence. It's as if I had
> asked why some people like to drive Porsches at 4mph and were to be
> given the reply "it matches the typical speed at which people walk".
> Even if it's true, it's hardly an answer.
It is of consequence because there is a correlation between 'then' and
{, and between 'end' and }. (An obvious one, IMO.)
>>
>> With a more elaborate if:
>>
>> if cond1 then
>> stmts1
>> elsif cond2 then
>> stmts2
>> else
>> stmts3
>> end if
>>
>> The block structure is very clear.
>
> In abbreviated form, yes. When the blocks are much larger, it is (in my
> view) less clear than Allman.
>
>> The 'then' ({) also obviously belongs
>> on the same line as the if or else, and each 'end' (}) obviously should
>> be in line with the corresponding if or else.
>
> Whenever I see the word "obviously" I get suspicious, and I'm suspicious
> now. *Why* is it obvious? (And in fact it isn't obvious to me.)
Because it follows the way you might write it in English, especially if
you wanted a tabulated format, as code is.
But mostly because that's the way it is invariably written in languages
that use 'if', 'then' and 'end' - Ada, Pascal and even Fortran now (and
Lua and Ruby for something less ancient. Python also, when it uses ':'
before an indented block. This ':' version of '{' goes on the same line
as what it follows).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-12 00:07 +0100 |
| Message-ID | <mircl0$6dm$1@dont-email.me> |
| In reply to | #61864 |
On 11/05/15 23:37, Bartc wrote:
> On 11/05/2015 21:18, Richard Heathfield wrote:
>> On 11/05/15 21:00, Bartc wrote:
>>> On 11/05/2015 20:04, Richard Heathfield wrote:
>
>>>> Does anyone have some other reason for preferring 1TBS?
>>>
>>> It matches the typical style of languages using if-then-else-end if:
>>>
>>> if more then
>>> second indent level
>>> end if
>>
>> That may well be true, but it's of no consequence. It's as if I had
>> asked why some people like to drive Porsches at 4mph and were to be
>> given the reply "it matches the typical speed at which people walk".
>> Even if it's true, it's hardly an answer.
>
> It is of consequence because there is a correlation between 'then' and
> {, and between 'end' and }. (An obvious one, IMO.)
If we are going to associate grouping tokens with the structure of
English (which is, in my view, a mistake), why would "if" and "then"
need to be grouped together? In English, we have:
protasis: if condition
apodosis: then result
The "then" belongs to the apodosis, not the protasis.
The code is far clearer, in my view, if the "if" stands alone.
<snip>
>>> The 'then' ({) also obviously belongs
>>> on the same line as the if or else, and each 'end' (}) obviously should
>>> be in line with the corresponding if or else.
>>
>> Whenever I see the word "obviously" I get suspicious, and I'm suspicious
>> now. *Why* is it obvious? (And in fact it isn't obvious to me.)
>
> Because it follows the way you might write it in English, especially if
> you wanted a tabulated format, as code is.
If the code followed the way I might write it in English, it wouldn't
start with main(). It would start "Once upon a time..." if it were being
written by Enid Blyton, or "The ancient Greeks..." if it were Asimov...
and so on. C is /not/ English, and it does not benefit from attempts to
make it read like English. It should be read like C. If you go too far
down the road you are suggesting, you end up with #define BEGIN { and
#define END } and so on.
> But mostly because that's the way it is invariably written in languages
> that use 'if', 'then' and 'end'
Invariably? Take Pascal, for instance, which uses BEGIN and END in the
same way that C uses { and }. Do you write:
IF foo THEN BEGIN
bar ;
baz ;
quux
END
?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-11 16:52 -0700 |
| Message-ID | <87sib2fz9t.fsf@kst-u.example.com> |
| In reply to | #61866 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 11/05/15 23:37, Bartc wrote:
[...]
>> But mostly because that's the way it is invariably written in languages
>> that use 'if', 'then' and 'end'
>
> Invariably? Take Pascal, for instance, which uses BEGIN and END in the
> same way that C uses { and }. Do you write:
>
> IF foo THEN BEGIN
> bar ;
> baz ;
> quux
> END
>
> ?
I've seen Pascal written in that style (not by me, though).
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-12 01:19 +0100 |
| Message-ID | <mirgss$idt$1@dont-email.me> |
| In reply to | #61866 |
On 12/05/2015 00:07, Richard Heathfield wrote:
> On 11/05/15 23:37, Bartc wrote:
>> But mostly because that's the way it is invariably written in languages
>> that use 'if', 'then' and 'end'
>
> Invariably? Take Pascal, for instance, which uses BEGIN and END in the
> same way that C uses { and }. Do you write:
>
> IF foo THEN BEGIN
> bar ;
> baz ;
> quux
> END
I forgot Pascal had begin...end. I didn't like that either and it makes
the same distinction between 1 statement and N statements that C does.
And I can't remember where I placed 'begin', it may well have been
in-line with the corresponding 'end'. The few samples I can find make
begin-end form a block with its own indentation level.
But at least begin-end results in a visually distinct block compared
with the weak ones you get with {,}:
begin
one;
two;
three
end
{
one;
two;
three;
}
where the {, } don't seem to be particularly attached to the contents of
their block!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-12 01:43 +0100 |
| Message-ID | <miri9b$li1$1@dont-email.me> |
| In reply to | #61869 |
On 12/05/15 01:19, Bartc wrote:
<snip>
> I forgot Pascal had begin...end. I didn't like that either and it makes
> the same distinction between 1 statement and N statements that C does.
>
> And I can't remember where I placed 'begin', it may well have been
> in-line with the corresponding 'end'. The few samples I can find make
> begin-end form a block with its own indentation level.
Right. Because that's where it makes sense. Same with {}.
> But at least begin-end results in a visually distinct block compared
> with the weak ones you get with {,}:
I don't see it as weak.
We're bordering on degustibus disputandum est, are we not?
> begin
> one;
> two;
> three
> end
>
> {
> one;
> two;
> three;
> }
>
> where the {, } don't seem to be particularly attached to the contents of
> their block!
But they are! It's obvious!
That is, it is obvious to me. One man's obvious is another man's obscure.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-05-12 11:00 +0000 |
| Message-ID | <5551dd30.929578@news.xs4all.nl> |
| In reply to | #61866 |
Richard Heathfield <rjh@cpax.org.uk> wrote:
> Invariably? Take Pascal, for instance, which uses BEGIN and END in the
> same way that C uses { and }. Do you write:
>
> IF foo THEN BEGIN
> bar ;
> baz ;
> quux
> END
Yes.
And the fact that you are _not allowed_ (not merely not required, but
actually disallowed) to add that last ; bugs me enormously.
Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-12 12:33 +0100 |
| Message-ID | <misocr$8ba$1@dont-email.me> |
| In reply to | #61893 |
On 12/05/15 12:00, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> Invariably? Take Pascal, for instance, which uses BEGIN and END in the
>> same way that C uses { and }. Do you write:
>>
>> IF foo THEN BEGIN
>> bar ;
>> baz ;
>> quux
>> END
>
> Yes.
I had been working at MumbleCo for about three weeks, I suppose, before
the immaculately besuited and entied co-worker opposite me finally
became exasperated by my rather more casual attire, and asked (in what
he undoubtedly thought was a firm but diplomatic manner) whether I had
worn jeans to my interview.
I now find myself as thrown by your "yes" as he was by mine.
>
> And the fact that you are _not allowed_ (not merely not required, but
> actually disallowed) to add that last ; bugs me enormously.
Pascal's (unofficial) motto: If you can't take a joke, you shouldn't
have joined.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-12 13:25 +0100 |
| Message-ID | <misrea$kc5$1@dont-email.me> |
| In reply to | #61893 |
On 12/05/2015 12:00, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> Invariably? Take Pascal, for instance, which uses BEGIN and END in the
>> same way that C uses { and }. Do you write:
>>
>> IF foo THEN BEGIN
>> bar ;
>> baz ;
>> quux
>> END
>
> Yes.
>
> And the fact that you are _not allowed_ (not merely not required, but
> actually disallowed) to add that last ; bugs me enormously.
The final semicolon isn't allowed for the same reason that a final comma
isn't allowed in this C code:
fn(
a,
b,
c
);
But I agree that it can be a nuisance when you want to re-order, delete,
or add statements, and you have to fiddle with adding and removing
semicolons from certain statements too. You don't often have to add
extra arguments to a function!
This is the annoying thing about (other people's) language design
choices; they will not add that extra bit of flexibility to make life
easier.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-05-17 10:01 +0000 |
| Message-ID | <55586577.3337671@news.xs4all.nl> |
| In reply to | #61898 |
Bartc <bc@freeuk.com> wrote:
> On 12/05/2015 12:00, Richard Bos wrote:
> > Richard Heathfield <rjh@cpax.org.uk> wrote:
> >
> >> Invariably? Take Pascal, for instance, which uses BEGIN and END in the
> >> same way that C uses { and }. Do you write:
> >>
> >> IF foo THEN BEGIN
> >> bar ;
> >> baz ;
> >> quux
> >> END
> >
> > Yes.
> >
> > And the fact that you are _not allowed_ (not merely not required, but
> > actually disallowed) to add that last ; bugs me enormously.
(I was wrong; this is only true before ELSE. I'm not sure whether that
idiosyncrasy is worse or not; in any case, I was taught that one
_shouldn't_ use ; as a terminator in Pascal, even if one can, and this
style still bugs me.)
> The final semicolon isn't allowed for the same reason that a final comma
> isn't allowed in this C code:
>
> fn(
> a,
> b,
> c
> );
That's a different case. The first one is similar to a sequence of
sentences in natural language, the second to a series of comma-separated
objects. IOW, the second doesn't bug me in the same way that it doesn't
bug me not to write "Tom, Dick, and Harry, went to sea"; the first one
does bug me in the same way it bugs me if the final sentence before a
sub-header is printed without a full stop.
Richard
[toc] | [prev] | [next] | [standalone]
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web