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 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 13:22 -0700 |
| Message-ID | <lnpp3zrce1.fsf@kst-u.example.com> |
| In reply to | #65169 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>Context: I prefer
>> if (condition) {
>> statement;
>> }
>
> Why do you put the semicolon »;« behind the statement?
Syntactically, the semicolon is part of the statement. I was being
informal (or sloppy if you prefer). Think of it as pseudo-code.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-10 20:47 +0000 |
| Message-ID | <mnpb04$5e0$1@speranza.aioe.org> |
| In reply to | #65169 |
Keith Thompson <kst-u@mib.org> wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
(snip, someone wrote)
>>> It doesn't bother me a whole lot. It frankly doesn't strike me as
>>> that big a deal one way or the other.
>> An interesting reponse. It seems like you're saying you've made
>> an arbitrary choice for no particular reason that you can
>> identify. Rather surprising. Thank you though for the response.
> Context: I prefer
> if (condition) {
> statement;
> }
> else if (condition) {
> statement;
> }
> else {
> statement;
> }
as I noted previously, I sometimes change depending on the
complexity of condition and statement.
If the statements are i=1;, i=2;, and i=3;, it doesn't seem
that there is a lot of need to space them out. It doesn't
take much thinking to absorb the meaning of such simple statements.
As they get more complicated, and require more thinking, I am
more inclined to give them more space, as the style above.
> over
> if (condition) {
> statement;
> } else if (condition) {
> statement;
> } else {
> statement;
> }
> You're right, I don't have any particular conscious reason for my
> preference (which differs from the style used in K&R, which was my
> original source for learning C).
So:
if(x>0 && y>0) i=0;
else if(x>0 && y<0) i=2;
else if(x<0 && y<0) i=3;
else i=4;
Doing it in four lines, insted of 12, doesn't seem, to me,
to make it less readable.
(Besides not being so consistent in the comparisons against zero.)
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 17:05 -0700 |
| Message-ID | <lnh9pbr220.fsf@kst-u.example.com> |
| In reply to | #65185 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> So:
>
> if(x>0 && y>0) i=0;
> else if(x>0 && y<0) i=2;
> else if(x<0 && y<0) i=3;
> else i=4;
>
> Doing it in four lines, insted of 12, doesn't seem, to me,
> to make it less readable.
>
> (Besides not being so consistent in the comparisons against zero.)
I've mentioned before, but didn't mention here, that I don't mind
omitting the braces and putting the whole if statement on one line if
it's short, especially if there are several parallel statements. There
aren't a whole lot of cases where I'd do this, but there are some.
I might write your example above as:
if (x > 0 && y > 0) i = 0;
else if (x > 0 && y < 0) i = 2;
else if (x < 0 && y < 0) i = 3;
else i = 4;
(I'm almost tempted to align the first "if" with the ones under it.)
--
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 | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-07-11 11:04 +0200 |
| Message-ID | <t8m1qa5kq81ni13k6h0m1vm4fqmnbv48vc@4ax.com> |
| In reply to | #65185 |
On Fri, 10 Jul 2015 20:47:00 +0000 (UTC), glen herrmannsfeldt wrote:
>Keith Thompson <kst-u@mib.org> wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>(snip, someone wrote)
>>>> It doesn't bother me a whole lot. It frankly doesn't strike me as
>>>> that big a deal one way or the other.
>
>>> An interesting reponse. It seems like you're saying you've made
>>> an arbitrary choice for no particular reason that you can
>>> identify. Rather surprising. Thank you though for the response.
>
>> Context: I prefer
>
>> if (condition) {
>> statement;
>> }
>> else if (condition) {
>> statement;
>> }
>> else {
>> statement;
>> }
>
>as I noted previously, I sometimes change depending on the
>complexity of condition and statement.
>
>If the statements are i=1;, i=2;, and i=3;, it doesn't seem
>that there is a lot of need to space them out. It doesn't
>take much thinking to absorb the meaning of such simple statements.
>
>As they get more complicated, and require more thinking, I am
>more inclined to give them more space, as the style above.
>
>> over
>
>> if (condition) {
>> statement;
>> } else if (condition) {
>> statement;
>> } else {
>> statement;
>> }
>
>> You're right, I don't have any particular conscious reason for my
>> preference (which differs from the style used in K&R, which was my
>> original source for learning C).
>
>So:
>
> if(x>0 && y>0) i=0;
> else if(x>0 && y<0) i=2;
> else if(x<0 && y<0) i=3;
> else i=4;
in one line of some not know/seen language (by me)
I(x>0&&y>0)i=0|E(x>0&&y<0)i=2|E(x<0&&y<0)i=3|E(1)i=4
in one readable line instead of 4...
as someone said "|" is better than ";" as separator statement
>Doing it in four lines, insted of 12, doesn't seem, to me,
>to make it less readable.
>(Besides not being so consistent in the comparisons against zero.)
>
>-- glen
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2015-07-11 18:06 +0800 |
| Message-ID | <mnqpo9$9u1$1@dont-email.me> |
| In reply to | #65236 |
Rosario19 wrote: > in one line of some not know/seen language (by me) > > I(x>0&&y>0)i=0|E(x>0&&y<0)i=2|E(x<0&&y<0)i=3|E(1)i=4 > > in one readable line instead of 4... > > as someone said "|" is better than ";" as separator statement Please get your space key repaired. Then this might approach readability. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-07-11 14:57 +0200 |
| Message-ID | <2j42qaltqecrgp9vov9pe5mqndjhrc7skl@4ax.com> |
| In reply to | #65246 |
On Sat, 11 Jul 2015 18:06:22 +0800, Reinhardt Behm <rbehm@hushmail.com> wrote: >Rosario19 wrote: > >> in one line of some not know/seen language (by me) >> >> I(x>0&&y>0)i=0|E(x>0&&y<0)i=2|E(x<0&&y<0)i=3|E(1)i=4 I(x>0&&y>0)i=0 E(x>0&&y<0)i=2 E(x<0&&y<0)i=3 E(1) i=4 this can be better >> >> in one readable line instead of 4... >> >> as someone said "|" is better than ";" as separator statement > >Please get your space key repaired. Then this might approach readability. only few spaces are need
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 09:20 -0700 |
| Message-ID | <kfnwpy6wtsb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65169 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
> [...]
>
>>>> It seems to me that the more consistent rule is to write
>>>> close brace on a line by itself when, and only when, it
>>>> is the end of the entire construct of which it is a part
>>>> (ie, including the if() or while(), etc, when a compound
>>>> statement is part of a larger statement); in cases where
>>>> it is part of something that continues on, like the above
>>>> examples or before the 'else' of an if()/else, then the
>>>> continuation would go on the same line. Yes?
>>>
>>> I suppose so.
>>>
>>>> I don't mean to deny your reaction. It's just that I
>>>> don't understand it. You don't know when you picked up
>>>> the habit, or why, but now it's a habit so you keep
>>>> doing it even though all there is in its favor is a
>>>> rationalization? Is this a fair summary?
>>>
>>> Sure.
>>>
>>>> If it is,
>>>> doesn't it seem a little bit dissatisfying? Or is there
>>>> some other force at play here that we just aren't aware
>>>> of yet?
>>>
>>> It doesn't bother me a whole lot. It frankly doesn't strike me as
>>> that big a deal one way or the other.
>>
>> An interesting reponse. It seems like you're saying you've made
>> an arbitrary choice for no particular reason that you can
>> identify. Rather surprising. Thank you though for the response.
>
> Context: I prefer
>
> if (condition) {
> statement;
> }
> else if (condition) {
> statement;
> }
> else {
> statement;
> }
>
> over
>
> if (condition) {
> statement;
> } else if (condition) {
> statement;
> } else {
> statement;
> }
>
> You're right, I don't have any particular conscious reason for my
> preference (which differs from the style used in K&R, which was my
> original source for learning C).
>
> But thinking about it now, I think of each 3-line sequence as a separate
> "block" (using that term informally). Adding blank lines:
>
> if (condition) {
> statement;
> }
>
> else if (condition) {
> statement;
> }
>
> else {
> statement;
> }
I find this conceptualization rather horrifying. It visually
suggests that the several components are independent, whereas
actually the opposite is true.
> Writing "} else {" feels a bit awkward to me; it puts the last line of
> one "block" on the same line as the first line of the following one.
I view the close brace as belonging to the if(), not the block;
only the contained statements form the "body" of an if() or
else/else if(). Visually that makes sense - the close brace is
at the same level of indentation as the if(). I know this point
of view is rather contra-syntactic, but IMO is a pragmatic
concession recognizing C not having proper IF/WHILE constructs.
Furthermore it aligns well with how C treats 'else' - you can't
tell when the if() has finished until you get to the 'else' (or
some other token).
> No doubt there are valid counterarguments, and I'm not going to object
> to anyone else using a different layout (within reason).
Like I've said in other places, I'm not really looking for
argument as much as I am tyring to understand other people's
perceptions and conceptualizations. Here I think we have hit
on a key one, which is you think of the closing brace in this
case as "belonging" to the group of statements before it.
I don't think of it as belonging to those statements; it ends
the group of statements but is outside of them, and part of
the if(). In this view it makes more sense to put close
braces on the same line as else/else if().
> In any case, the style I use (which has evolved over time) is IMHO as
> consistent as it needs to be. It's unlikely to be visually painful
> for any reader who doesn't already hate putting "{" at the end of
> a line. Any effort I expend thinking about how to improve it is
> likely to outweigh the benefits. Of course I reserve the right to
> change my mind. (And of course, when working on code that I don't
> own I follow its coding conventions rather than my own preferences.)
Just as a point of information it is visually painful for me.
Also I see it as somewhat error prone, since it might easily
lead to cases where an if() statement is seen to be complete
when in fact it is not. (And this kind of misperception is
one that has actually happened for me, so I know it can happen.)
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-11 20:06 +0000 |
| Message-ID | <mnrt13$f0l$1@speranza.aioe.org> |
| In reply to | #65303 |
Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Keith Thompson <kst-u@mib.org> writes:
(snip)
>> But thinking about it now, I think of each 3-line sequence as a separate
>> "block" (using that term informally). Adding blank lines:
>> if (condition) {
>> statement;
>> }
>>
>> else if (condition) {
>> statement;
>> }
>>
>> else {
>> statement;
>> }
> I find this conceptualization rather horrifying. It visually
> suggests that the several components are independent, whereas
> actually the opposite is true.
Lately I have been working more in VHDL which has an ELSIF very
distinct from ELSE IF. If you use ELSE IF, you need the
appropriate number of END IF (but not ENDIF), but with ELSIF
only one END IF. Seems to me that they are as independent
as cases in a switch.
>> Writing "} else {" feels a bit awkward to me; it puts the last line of
>> one "block" on the same line as the first line of the following one.
> I view the close brace as belonging to the if(), not the block;
> only the contained statements form the "body" of an if() or
> else/else if().
Hmmm. Before learning C, the block structured language that
I used most was PL/I, which has DO; and END; where C has { and }.
Being statements instead of punctuation makes it harder to
consider them as part of the IF. I am not so sure, but that
might be why I consider the } as part of the block, not the if.
> Visually that makes sense - the close brace is
> at the same level of indentation as the if(). I know this point
> of view is rather contra-syntactic, but IMO is a pragmatic
> concession recognizing C not having proper IF/WHILE constructs.
> Furthermore it aligns well with how C treats 'else' - you can't
> tell when the if() has finished until you get to the 'else' (or
> some other token).
>> No doubt there are valid counterarguments, and I'm not going to object
>> to anyone else using a different layout (within reason).
> Like I've said in other places, I'm not really looking for
> argument as much as I am tyring to understand other people's
> perceptions and conceptualizations. Here I think we have hit
> on a key one, which is you think of the closing brace in this
> case as "belonging" to the group of statements before it.
> I don't think of it as belonging to those statements; it ends
> the group of statements but is outside of them, and part of
> the if(). In this view it makes more sense to put close
> braces on the same line as else/else if().
How much programming using a language with IF/ENDIF did you
do before starting C?
>> In any case, the style I use (which has evolved over time) is IMHO as
>> consistent as it needs to be. It's unlikely to be visually painful
>> for any reader who doesn't already hate putting "{" at the end of
>> a line. Any effort I expend thinking about how to improve it is
>> likely to outweigh the benefits. Of course I reserve the right to
>> change my mind. (And of course, when working on code that I don't
>> own I follow its coding conventions rather than my own preferences.)
> Just as a point of information it is visually painful for me.
> Also I see it as somewhat error prone, since it might easily
> lead to cases where an if() statement is seen to be complete
> when in fact it is not. (And this kind of misperception is
> one that has actually happened for me, so I know it can happen.)
Some years ago, I was doing a lot of TeX programming where matching
{ and } is much more of a problem than in C. The vi % command was
very useful in getting them right. Sometimes I would insert a }
and the end of a file, or { at the beginning, then see where
it matched. Not so often in C, but sometimes.
As an extra challenge, there are programs with, for example:
printf("{");
in them, which gets the count wrong as seen by vi. I might:
printf("{"); /* } */
(C 90 days) to get them to match.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 04:55 -0700 |
| Message-ID | <kfny4ihskid.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65329 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>
> (snip)
>
>>> But thinking about it now, I think of each 3-line sequence as a separate
>>> "block" (using that term informally). Adding blank lines:
>>>
>>> if (condition) {
>>> statement;
>>> }
>>>
>>> else if (condition) {
>>> statement;
>>> }
>>>
>>> else {
>>> statement;
>>> }
>>
>> I find this conceptualization rather horrifying. It visually
>> suggests that the several components are independent, whereas
>> actually the opposite is true.
>
> Lately I have been working more in VHDL which has an ELSIF very
> distinct from ELSE IF. If you use ELSE IF, you need the
> appropriate number of END IF (but not ENDIF), but with ELSIF
> only one END IF. Seems to me that they are as independent
> as cases in a switch.
Semantically the different branches of an if()/else if()/else
are independent. Syntactically they aren't. Moreover the
point I am making is not about the bodies but about the glue
that holds the construct together - for me the braces are
part of the glue, not part of the sequence of statements
that make up the individual bodies.
>>> Writing "} else {" feels a bit awkward to me; it puts the last line of
>>> one "block" on the same line as the first line of the following one.
>>
>> I view the close brace as belonging to the if(), not the block;
>> only the contained statements form the "body" of an if() or
>> else/else if().
>
> Hmmm. Before learning C, the block structured language that
> I used most was PL/I, which has DO; and END; where C has { and }.
> Being statements instead of punctuation makes it harder to
> consider them as part of the IF. I am not so sure, but that
> might be why I consider the } as part of the block, not the if.
That sounds possible.
>> Visually that makes sense - the close brace is
>> at the same level of indentation as the if(). I know this point
>> of view is rather contra-syntactic, but IMO is a pragmatic
>> concession recognizing C not having proper IF/WHILE constructs.
>> Furthermore it aligns well with how C treats 'else' - you can't
>> tell when the if() has finished until you get to the 'else' (or
>> some other token).
>>
>>> No doubt there are valid counterarguments, and I'm not going to object
>>> to anyone else using a different layout (within reason).
>>
>> Like I've said in other places, I'm not really looking for
>> argument as much as I am tyring to understand other people's
>> perceptions and conceptualizations. Here I think we have hit
>> on a key one, which is you think of the closing brace in this
>> case as "belonging" to the group of statements before it.
>> I don't think of it as belonging to those statements; it ends
>> the group of statements but is outside of them, and part of
>> the if(). In this view it makes more sense to put close
>> braces on the same line as else/else if().
>
> How much programming using a language with IF/ENDIF did you
> do before starting C?
I don't remember using any language (except pseudo-code) with
ENDIF or equivalent. Oh, I take that back - there is the
Dijkstra language that has if/fi and do/od, which I wrote
some programs in for a course while I was at school, and
that was before C. But mostly the "comb" style of control
flow constructs came from seeing/writing pseudo-code, which
I adapted to all the different programming languages I was
working in.
>>> In any case, the style I use (which has evolved over time) is IMHO as
>>> consistent as it needs to be. It's unlikely to be visually painful
>>> for any reader who doesn't already hate putting "{" at the end of
>>> a line. Any effort I expend thinking about how to improve it is
>>> likely to outweigh the benefits. Of course I reserve the right to
>>> change my mind. (And of course, when working on code that I don't
>>> own I follow its coding conventions rather than my own preferences.)
>>
>> Just as a point of information it is visually painful for me.
>> Also I see it as somewhat error prone, since it might easily
>> lead to cases where an if() statement is seen to be complete
>> when in fact it is not. (And this kind of misperception is
>> one that has actually happened for me, so I know it can happen.)
>
> Some years ago, I was doing a lot of TeX programming where matching
> { and } is much more of a problem than in C. The vi % command was
> very useful in getting them right. Sometimes I would insert a }
> and the end of a file, or { at the beginning, then see where
> it matched. Not so often in C, but sometimes.
TeX surely is one of the candidates for the world's
most unusable programming languages.
> As an extra challenge, there are programs with, for example:
>
> printf("{");
>
> in them, which gets the count wrong as seen by vi. I might:
>
> printf("{"); /* } */
>
> (C 90 days) to get them to match.
Sort of sad that vi gets that wrong.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 13:26 -0700 |
| Message-ID | <lnzj32phjt.fsf@kst-u.example.com> |
| In reply to | #65303 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> But thinking about it now, I think of each 3-line sequence as a separate
>> "block" (using that term informally). Adding blank lines:
>>
>> if (condition) {
>> statement;
>> }
>>
>> else if (condition) {
>> statement;
>> }
>>
>> else {
>> statement;
>> }
>
> I find this conceptualization rather horrifying. It visually
> suggests that the several components are independent, whereas
> actually the opposite is true.
No, they're not independent. Each one logically depends on the "blocks"
that precede it, and certainly the order is significant (unless the
conditions happen to be exclusive). I suppose I think of that as the
semantics of the if/else; I don't feel the need to reflect it in the
layout.
It's structurally similar to a switch statement (of course there are
semantic differences) (excessive whitespace added to show the
structure):
switch (value) {
case const1:
...
break;
case const2:
...
break;
default:
...
break;
}
If I really wanted an if/else chain's layout to closely reflect both the
syntax and the samantics, I'd write it like this:
if (condition) {
statement;
}
else {
if (condition) {
statement;
}
else {
if (condition) {
statement;
}
else {
statement;
}
}
}
But the linear chain is a very common idiom, and IMHO easier to
understand.
[...]
>> In any case, the style I use (which has evolved over time) is IMHO as
>> consistent as it needs to be. It's unlikely to be visually painful
>> for any reader who doesn't already hate putting "{" at the end of
>> a line. Any effort I expend thinking about how to improve it is
>> likely to outweigh the benefits. Of course I reserve the right to
>> change my mind. (And of course, when working on code that I don't
>> own I follow its coding conventions rather than my own preferences.)
>
> Just as a point of information it is visually painful for me.
> Also I see it as somewhat error prone, since it might easily
> lead to cases where an if() statement is seen to be complete
> when in fact it is not. (And this kind of misperception is
> one that has actually happened for me, so I know it can happen.)
So you write
} else {
rather than
}
else {
so the "blocks" are more closely tied together?
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 06:29 -0700 |
| Message-ID | <kfntwt5sg5p.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65333 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> But thinking about it now, I think of each 3-line sequence as a separate
>>> "block" (using that term informally). Adding blank lines:
>>>
>>> if (condition) {
>>> statement;
>>> }
>>>
>>> else if (condition) {
>>> statement;
>>> }
>>>
>>> else {
>>> statement;
>>> }
>>
>> I find this conceptualization rather horrifying. It visually
>> suggests that the several components are independent, whereas
>> actually the opposite is true.
>
> No, they're not independent. Each one logically depends on the "blocks"
> that precede it, and certainly the order is significant (unless the
> conditions happen to be exclusive). I suppose I think of that as the
> semantics of the if/else; I don't feel the need to reflect it in the
> layout.
What is more important is that the "pieces" are part of a larger
syntactic (and semantic) structure. Attaching a close brace to a
"piece" rather than to an 'else if()/else' line makes it look
like the larger structure has ended. What you (tacitly) call
"not reflecting" strikes me as deliberately misleading, like the
misdirection in a magic trick. (To be clear I don't mean to
accuse you of any bad intentions, only that this is how I react
upon seeing it.) I should be able to read one line at a time and
see what's going one; if a close brace is separated from its
adjoining else I can't do that. It's like, okay, there's the
close brace, that's the end of that if(). Then, next line, ha!,
fooled you, now here's an else.. I get an annoying double-take
reaction every time it happens.
> It's structurally similar to a switch statement (of course there are
> semantic differences) (excessive whitespace added to show the
> structure):
>
> switch (value) {
>
> case const1:
> ...
> break;
>
> case const2:
> ...
> break;
>
> default:
> ...
> break;
>
> }
The /effect/ is similar, but at a structural level this is
nothing like if()/else if()/else. A switch() statement has outer
braces that contain and delimit the entire set of alternatives.
When I get to a 'break;' in one of the cases of a switch(), I
don't need to check to see if that's the end of the switch() -
that happens only at the outer closing brace. If if() statements
were written using a different syntax, eg,
if {
if test1 :
...
if test2 :
...
else :
...
}
/now/ we have a construct that is structurally similar to
switch(). Notice there is no problem about where to put
delimiting braces, because here we don't need any.
> If I really wanted an if/else chain's layout to closely reflect both the
> syntax and the samantics, I'd write it like this:
>
> if (condition) {
> statement;
> }
> else {
> if (condition) {
> statement;
> }
> else {
> if (condition) {
> statement;
> }
> else {
> statement;
> }
> }
> }
>
> But the linear chain is a very common idiom, and IMHO easier to
> understand.
My intention is both to be consistent with the actual syntax and
to reflect the (or my) conceptual syntax. In my perception the
above way of writing if()'s fails both parts - the first because
of brace placement, the second because of nesting not matching
the (presumed) conceptual structure. Note also that there are
cases where
if (condition) {
...
} else {
if (another condition) {
...
} else {
...
}
}
is a better writing than a single linear sequence, because it
corresponds to how the author conceptualizes the sets of
tests and actions in question.
> [...]
>
>>> In any case, the style I use (which has evolved over time) is IMHO as
>>> consistent as it needs to be. It's unlikely to be visually painful
>>> for any reader who doesn't already hate putting "{" at the end of
>>> a line. Any effort I expend thinking about how to improve it is
>>> likely to outweigh the benefits. Of course I reserve the right to
>>> change my mind. (And of course, when working on code that I don't
>>> own I follow its coding conventions rather than my own preferences.)
>>
>> Just as a point of information it is visually painful for me.
>> Also I see it as somewhat error prone, since it might easily
>> lead to cases where an if() statement is seen to be complete
>> when in fact it is not. (And this kind of misperception is
>> one that has actually happened for me, so I know it can happen.)
>
> So you write
>
> } else {
>
> rather than
>
> }
> else {
Yes, always.
> so the "blocks" are more closely tied together?
So the construct as a whole is tied together. By "block" (or
maybe "body" is better) I mean only those statements inside
the enclosing braces, not the braces themselves. If I want
space after the "body" of an if() or else/else if(), as I
sometimes do, I would write it like so:
if(...){
...
} else if(...){
...
} else {
...
}
because as I conceptualize the construct the "body" under
the if() doesn't end until the else if(), the "body" under
an else if() doesn't end until the next else if() or else,
etc - again, to be clear, as I conceptualize the structure.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-20 13:49 -0700 |
| Message-ID | <kfn1tibas9y.fsf@x-alumni2.alumni.caltech.edu> |
| 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?
>
> 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?
Sorry for the delay in responding. I would like to give
an answer but it's more just my own reactions than reasons
or arguments. (I see there have been lots of other replies,
but mostly I haven't read these yet.)
For me, putting these open braces on a line by themselves is all
cost and no benefit. The biggest cost is distraction cost - they
don't tell me anything I don't already know, but insist on
focusing my attention on their presence. When reading code, for
me anyway, fully present attention is in short supply, and I need
all I can get - I don't want it taken away for something that
provides no benefit.
A secondary reason is confusion cost. If I see
if (something)
{
...
}
at the end of a screen, or
{
...
}
at the beginning of a screen, in code written in Allman style, I
have to wonder (or look) to see if there is something on the next
(or previous, in the second case) screen that is relevant, eg, a
dangling 'if()' or 'else' line. (Incidentally, the same problem
occurs, to a lesser degree, for code written using the Stroustrup
style -
https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup
.) These possible confusions don't occur for code written in
1TBS style. About the only place I put open braces on lines by
themselves is for stand-alone compound statements (ie, that are
not subsidiary to if() or while(), etc), and those don't occur
too often.
The space cost (ie, the extra lines taken up by some braces being
on lines by themselves, rather than on the same lines as if or
else or while) usually doesn't affect readability locally, but
sometimes it does (for longer functions), and it also has process
costs. My measurements show Allman style takes up about 9 or 10
percent more space than it would if written using 1TBS. That's
ten percent more pages to read, ten percent more "next screen"
commands, and a correspondingly lower S/N ratio. The cost may
be small, but it is definitely greater than zero.
I do have another reaction which is a little harder to put into
words, something related to consistency and the mechanics of how
I read code. Normally I read code one line at a time. As much
as possible (at least reasonably possible) the start of a line
should be a break between statements, and a statement should be
either complete on a single line or written in a way that there
is no question at the end of the (first) line that more is
coming up, and what form that is. If I see a line that says
this
if (a > b)
I have to look at the next line to know whether what follows is a
single unbraced statement or a compound statement (or worse, a
comment). Morever the next line starts in the middle of a
statement, not between statements. Conversely, if I see
if (a > b) {
I don't have to look or wonder about what's going on - the open
brace tells me right away. I admit that usually this effect is
negligible, but not always (eg, end of page/screen); here
again the cost is non-zero. I don't want to pay these costs
for something that, to me, provides no benefit.
(More to say but this is a pretty clean stopping point so
let me stop here and hope to resume later.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-21 07:12 -0700 |
| Message-ID | <kfnoale9fz9.fsf@x-alumni2.alumni.caltech.edu> |
| 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?
Now I would like to turn this around and ask you to explain
what advantage you see in the first one, that compensates
for the visual clutter and wasted lines that 1TBS avoids?
> 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?
The only explanation (or argument, if you want to call it that) I
have heard for Allman style, as pertains to readability, are
things like "it's clear" or "it's logical". The comment above
about visual reinforcement of code structure more or less falls
into this category - I don't really learn anything from it that
doesn't seem circular. Several folks have responded in answer to
your question (and I have now read through those), and each gave
one or more factors that play into their reaction. What can you
say along those kinds of lines about your own factors?
Incidentally, I understand there are also process reasons (such
as when editing) that may be a factor here, but I would like to
keep those separate for the time being.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-21 15:26 +0000 |
| Message-ID | <mjktfo$3rj$1@speranza.aioe.org> |
| In reply to | #62406 |
Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
(snip)
>> 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.
I pretty much never put the opening brace (or BEGIN or DO) on a
line by itself. It doesn't look more clear, or more readable, to me.
(snip example with opening braces moved)
>> 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?
> Now I would like to turn this around and ask you to explain
> what advantage you see in the first one, that compensates
> for the visual clutter and wasted lines that 1TBS avoids?
>> 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
(snip)
>> Does anyone have some other reason for preferring 1TBS?
I am not sure waht 1TBS is, but ...
> The only explanation (or argument, if you want to call it that) I
> have heard for Allman style, as pertains to readability, are
> things like "it's clear" or "it's logical". The comment above
> about visual reinforcement of code structure more or less falls
> into this category - I don't really learn anything from it that
> doesn't seem circular. Several folks have responded in answer to
> your question (and I have now read through those), and each gave
> one or more factors that play into their reaction. What can you
> say along those kinds of lines about your own factors?
It might be from years editing on 24 line screens, and even printing
on 60 line paper. With proper indenting, the beginning and ending
of blocks is already visible. Extra blank, or one character lines,
don't make it more visible.
> Incidentally, I understand there are also process reasons (such
> as when editing) that may be a factor here, but I would like to
> keep those separate for the time being.
As noted above, I don't know that you can separate them. I do find
it easier to work on a block that fits in a screen/window on the
screen. Fewer blank, or almost blank lines, helps.
I also put single statements that go with if() or for() on the
same line as the if() or for(), unless the result is unusually long.
OK, consider the readability:
for(i=0; i<100; i++) x[i]=2;
vs.
for(i=0; i<100; i++)
{
x[i]=2;
}
For one, note that a very simple statement follows the for.
In Fortran (90 or later) this would be:
x=2
so adding the for() already makes it less readable.
It should take very little time for the reader to figure out
what is happening, and extra lines don't make it easier.
But as the loop contents becomes more complicated, a little
more space does help. It is a balance, and one rule doesn't
work everywhere.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-22 11:36 -0500 |
| Message-ID | <mjnls9$s8j$1@dont-email.me> |
| In reply to | #62408 |
On 21-May-15 10:26, glen herrmannsfeldt wrote:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> 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
>>>
>>> Does anyone have some other reason for preferring 1TBS?
>
> I am not sure waht 1TBS is, but ...
The One True Brace Style (1TBS) is this:
if (foo) {
bar();
} else {
baz();
}
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-24 13:50 -0700 |
| Message-ID | <kfn617h7l8w.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62408 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>
> (snip)
>
>>> 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.
>> [snip]
>> Incidentally, I understand there are also process reasons (such
>> as when editing) that may be a factor here, but I would like to
>> keep those separate for the time being.
>
> As noted above, I don't know that you can separate them. [snip]
It's an easy distinction - I am asking about factors that affect
/reading/ of code, as opposed to other development activities.
If it makes a difference to reading, it's in, and if it doesn't
it's out. If it matters, reading that is done as part of another
activity (eg debugging) also is included. What I mean to rule
out are things like, eg, "doing X makes it easy to add assert()'s
later". That might be good to know, but it's not what I'm asking
about.
> I also put single statements that go with if() or for() on the
> same line as the if() or for(), unless the result is unusually
> long.
It hadn't occurred to me before, but I wonder whether a
willingness to do that correlates with choice of open brace
placement. Certainly it might.
> [various examples with for()]
>
> But as the loop contents becomes more complicated, a little
> more space does help. It is a balance, and one rule doesn't
> work everywhere.
Do you mean considering where to put the braces (if any), or
considering how many lines the loop should take up (including
blank lines, if any)? IME (or IMO if that's better) there is
often some degree of individual variation in the latter, but none
in the former.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-24 23:01 +0000 |
| Message-ID | <mjtl8s$rfu$1@speranza.aioe.org> |
| In reply to | #62547 |
Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>> Incidentally, I understand there are also process reasons (such
>>> as when editing) that may be a factor here, but I would like to
>>> keep those separate for the time being.
(snip, then I wrote)
>> As noted above, I don't know that you can separate them. [snip]
> It's an easy distinction - I am asking about factors that affect
> /reading/ of code, as opposed to other development activities.
> If it makes a difference to reading, it's in, and if it doesn't
> it's out. If it matters, reading that is done as part of another
> activity (eg debugging) also is included. What I mean to rule
> out are things like, eg, "doing X makes it easy to add assert()'s
> later". That might be good to know, but it's not what I'm asking
> about.
I mean the difference between reading listings on paper, and
while editing on a screen editor. The fonts are different, and
so is the visual effect.
>> I also put single statements that go with if() or for() on the
>> same line as the if() or for(), unless the result is unusually
>> long.
> It hadn't occurred to me before, but I wonder whether a
> willingness to do that correlates with choice of open brace
> placement. Certainly it might.
>> [various examples with for()]
>> But as the loop contents becomes more complicated, a little
>> more space does help. It is a balance, and one rule doesn't
>> work everywhere.
> Do you mean considering where to put the braces (if any), or
> considering how many lines the loop should take up (including
> blank lines, if any)? IME (or IMO if that's better) there is
> often some degree of individual variation in the latter, but none
> in the former.
Whether a simple statement goes on the line with the if()/for(),
or a more complicated or longer one goes inside { and } in the
usual way. That is, it could go on one line.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 08:42 -0700 |
| Message-ID | <kfnio9s6mtr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62561 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>>> Incidentally, I understand there are also process reasons (such
>>>> as when editing) that may be a factor here, but I would like to
>>>> keep those separate for the time being.
>
> (snip, then I wrote)
>
>>> As noted above, I don't know that you can separate them. [snip]
>>
>> It's an easy distinction - I am asking about factors that affect
>> /reading/ of code, as opposed to other development activities.
>> If it makes a difference to reading, it's in, and if it doesn't
>> it's out. If it matters, reading that is done as part of another
>> activity (eg debugging) also is included. What I mean to rule
>> out are things like, eg, "doing X makes it easy to add assert()'s
>> later". That might be good to know, but it's not what I'm asking
>> about.
>
> I mean the difference between reading listings on paper, and
> while editing on a screen editor. The fonts are different, and
> so is the visual effect.
Both of these are reading. I'm asking about both, without
distinction. I don't mind an answer that distinguishes the two
cases, but what I'm asking about covers both kinds of reading.
>>> I also put single statements that go with if() or for() on the
>>> same line as the if() or for(), unless the result is unusually
>>> long.
>>
>> It hadn't occurred to me before, but I wonder whether a
>> willingness to do that correlates with choice of open brace
>> placement. Certainly it might.
>>
>>> [various examples with for()]
>>>
>>> But as the loop contents becomes more complicated, a little
>>> more space does help. It is a balance, and one rule doesn't
>>> work everywhere.
>>
>> Do you mean considering where to put the braces (if any), or
>> considering how many lines the loop should take up (including
>> blank lines, if any)? IME (or IMO if that's better) there is
>> often some degree of individual variation in the latter, but none
>> in the former.
>
> Whether a simple statement goes on the line with the if()/for(),
> or a more complicated or longer one goes inside { and } in the
> usual way. That is, it could go on one line.
What I think you're describing is "use one or the other, as
various considerations or other factors may dictate". That rule
isn't mechanical, but it is one rule that covers all cases
(and not just vacuously). It also matches what I believe is
what you're doing.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-10 17:37 +0000 |
| Message-ID | <mnovsl$9qb$1@speranza.aioe.org> |
| In reply to | #65121 |
Tim Rentsch <txr@alumni.caltech.edu> wrote:
(snip, I wrote)
>> I mean the difference between reading listings on paper, and
>> while editing on a screen editor. The fonts are different, and
>> so is the visual effect.
> Both of these are reading. I'm asking about both, without
> distinction. I don't mind an answer that distinguishes the two
> cases, but what I'm asking about covers both kinds of reading.
(snip, someone wrote)
>>> Do you mean considering where to put the braces (if any), or
>>> considering how many lines the loop should take up (including
>>> blank lines, if any)? IME (or IMO if that's better) there is
>>> often some degree of individual variation in the latter, but none
>>> in the former.
>> Whether a simple statement goes on the line with the if()/for(),
>> or a more complicated or longer one goes inside { and } in the
>> usual way. That is, it could go on one line.
> What I think you're describing is "use one or the other, as
> various considerations or other factors may dictate". That rule
> isn't mechanical, but it is one rule that covers all cases
> (and not just vacuously). It also matches what I believe is
> what you're doing.
Yes. Mostly I actually look at the resutls and see which
one I like the look of.
I try to keep program lines somewhat less than 80 characters.
(Among others, they print better, and also look better on 80
character screens.) I like them closer to 50 or 60.
If an 'if' statement and a single statement controlled by that if,
ends by column 50 or 60 (that includes indentation) I probably
choose that. It it gets to column 70 or so, probably separate lines.
It might even depend on the complexity of the statement, and
the need to add comments to the statement.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-10 10:59 -0700 |
| Message-ID | <300018e8-ca2d-4627-82da-037887ad98fd@googlegroups.com> |
| In reply to | #65148 |
On Friday, July 10, 2015 at 10:37:36 AM UTC-7, glen herrmannsfeldt wrote:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
> (snip, I wrote)
> >> I mean the difference between reading listings on paper, and
> >> while editing on a screen editor. The fonts are different, and
> >> so is the visual effect.
>
> > Both of these are reading. I'm asking about both, without
> > distinction. I don't mind an answer that distinguishes the two
> > cases, but what I'm asking about covers both kinds of reading.
>
> (snip, someone wrote)
> >>> Do you mean considering where to put the braces (if any), or
> >>> considering how many lines the loop should take up (including
> >>> blank lines, if any)? IME (or IMO if that's better) there is
> >>> often some degree of individual variation in the latter, but none
> >>> in the former.
>
> >> Whether a simple statement goes on the line with the if()/for(),
> >> or a more complicated or longer one goes inside { and } in the
> >> usual way. That is, it could go on one line.
>
> > What I think you're describing is "use one or the other, as
> > various considerations or other factors may dictate". That rule
> > isn't mechanical, but it is one rule that covers all cases
> > (and not just vacuously). It also matches what I believe is
> > what you're doing.
>
> Yes. Mostly I actually look at the resutls and see which
> one I like the look of.
>
> I try to keep program lines somewhat less than 80 characters.
> (Among others, they print better, and also look better on 80
> character screens.) I like them closer to 50 or 60.
>
> If an 'if' statement and a single statement controlled by that if,
> ends by column 50 or 60 (that includes indentation) I probably
> choose that. It it gets to column 70 or so, probably separate lines.
>
> It might even depend on the complexity of the statement, and
> the need to add comments to the statement.
I don't like to do this because I am not talking about C.
I think readibility would be improved if blocks of code were moved
out of the mainline. For example
if (...) do X;
else do Y;
where are X and Y are descriptive labels. The code for X and Y is
somewhere else.
To some extent you can do this in C with functions - but it is easy
to get in trouble with variables -
if (...) do_such_and_such ();
else do_something_different ();
But this is not really a satisfactory solution - even if you declare
do_such_and_such as inline.
One improvement over C would be to allow do_such_and_such to be a
function embedded in the larger function. C does not allow that (Pascal
did and Intel thought enough of it to add an instruction to facilitate
it - but that is another story).
C is good - but not perfect.
[toc] | [prev] | [next] | [standalone]
Page 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web