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 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 07:23 -0700 |
| Message-ID | <kfnpp3tsdnn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65352 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> Tim Rentsch wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>>> Tim Rentsch wrote: >>>>> >>>>>> Hmmm. Are you saying that >>>>>> >>>>>> (a) using an additional line has a cost but the cost is minor; >>>>>> (b) using an additional line has no cost; or >>>>>> (c) using an additional line is a benefit? >>>>> >>>>> Answered in reply to another post before I read this one. >>>> >>>> I read (and responded) to your other posting, but I don't >>>> see how it addresses or answers this question. >>> >>> I would say yes to (a) and (c). >> >> My question was meant as choose only one, but thank you >> for the answer. > > The choices weren't mutually exclusive! They were meant to be mutually exclusive in what I was trying to ask. Sorry not to have expressed that more clearly. >>> Yes on a tiny screen the extra line may have a cost in terms of >>> visible code. >> >> It should have roughly the same percentage cost on all >> screens, regardless of size. > > Correct, but the importance of layout changes with screen size. With > a small screen (or in a book) you want to see a much code as possible, > so a condensed style is better. With a larger screen aesthetics are > more important: we see more of the bigger picture. So I guess you > could say my preferred style reflects my preferred development > environment. This sounds like the same argument in a different guise: for you the benefit of putting open braces on lines by themselves outweighs the cost of taking extra space, because the placement by itself has value. If you were forced to work in an environment where your display was limited to, say, 40 lines, do you think your layout preference would change? That strikes me as pretty unlikely. You are probably right that the space cost is less of a burden with 100+ lines to work with, but I doubt that it's as much less as just dividing two sizes would suggest. Human visual systems have ergonomic limits independent of the display medium. For example, reading prose the widest lines that are comfortable is somewhere in the range of 70 to 75 characters; if you try to read ordinary text that is much wider, such as 90 characters, I think you will find it is fairly difficult over any significant period. It's no accident that almost all books observe about the same width limit. Similarly I'm sure there is a limit in height for what the human eye is comfortable reading, and text of any sort that is 10% longer is going to bump into that limit more often. I think it's more likely that your preferred development environment is a consequence of your preferred layout style than the other way around. Would you agree? >>> On a decent screen (my current IDE window has 550 lines >>> of visible code!) to my eye it makes it easier to read. >> >> Presumably you are counting multiple columns, since if it >> were a single column (assuming 8 point type, which is >> already pretty small) the screen would be over 5 feet tall. > > Yes, I have 5 columns, with a 12 point font. > >> In any case, whether it is single column or multi-column, >> the cost is still about 10% (and here I am assuming that >> most of the files you're looking at are more than a single >> column-height long, which I think is a fair assumption). > > It probably is, but the benefit outweighs the cost. Not to repeat the point unduly, the benefit as you perceive or conceptualize the structure. In my perception the benefit in this case is negative, making it all loss and no gain.
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2015-05-11 13:30 -0700 |
| Message-ID | <c00f61d5-1361-4424-8b89-3f15a1b8ddb3@googlegroups.com> |
| In reply to | #61856 |
On Monday, May 11, 2015 at 3:05:06 PM UTC-4, Richard Heathfield wrote:
> 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;
> }
You can also have a mix of both vertical and 1TBS style, which is what
I use to reduce some of the vertical travesties that happen with long
if/else with single statements that you run into once in a while.
if (...)
{
blah;
}
else if (...)
{
blah blah;
}
...
else
{
blah-ed out;
}
int foo(parms)
{
first indent level;
if (more) {
second indent level single stmt;
}
else
{
second indent level multiple stmt1;
second indent level multiple stmt2;
second indent level multiple stmt3;
}
return bar;
}
Typically, if the size of "second indent level;" is one statement, I use
the 1TBS. For multiple statements, I use vertical alignment.
int foo(parms)
{
first indent level;
if (more) {
second indent level;
}
else
{
second indent stmt1;
second indent stmt2;
second indent stmt3;
}
if (more) {
second indent level single stmt;
}
else if (more_or_less) {
second indent level single stmt;
}
else if (less_is_more)
{
second indent level multiple stmt1;
second indent level multiple stmt2;
second indent level multiple stmt3;
}
else {
second indent level single stmt;
}
/* But I'm also not consistent, as I also do this for single
statements in the if and else clause. */
if (more) {
second indent level single stmt;
} else {
second indent level single stmt;
}
return bar;
}
I'm not fond of 1TBS on function definitions, as I like to scan vertically
for brace mismatches if I stumble creating the right pairing with a function
with large amounts of nested blocks. 1TBS makes it harder for me to
resolve the "matching brace" problem.
So I really prefer 1TBS for blocks that contain one statement, such as
for/while/if/else (...) {
single statement;
}
But again I'm not completely consistent since I often do this:
do
{
single statement;
} while (...);
I have changed my style several times since starting programming, but I
haven't deviated from this style for a while now.
Best regards,
John D.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-11 21:56 +0100 |
| Message-ID | <mir4vh$84r$1@dont-email.me> |
| In reply to | #61861 |
On 11/05/15 21:30, jadill33@gmail.com wrote: <snip> > I'm not fond of 1TBS on function definitions, as I like to scan vertically > for brace mismatches if I stumble creating the right pairing with a function > with large amounts of nested blocks. 1TBS makes it harder for me to > resolve the "matching brace" problem. I would very much agree with this. As a (g)vim user, I can of course toggle between matching braces using % - and if I do so, to find that the cursor is leaping between columns, it's a dead giveaway that I'm missing a brace somewhere (or, of course, that I have a superfluous brace, meaning that it's time for a punctuectomy). With 1TBS, that visual clue would be absent, or at least less inyerface. <snip> > But again I'm not completely consistent "A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson. <snip> -- 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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-11 23:14 -0500 |
| Message-ID | <mirukd$jfa$1@dont-email.me> |
| In reply to | #61856 |
On 11-May-15 14:04, Richard Heathfield wrote:
> On 11/05/15 19:47, Stephen Sprunk wrote:
>> 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:
> [Allman style example]
> 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:
> [1TBS example]
> 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?
For such a simple example, there isn't that much difference. Part of me
likes Allman's vertical alignment of the braces, but I don't find it
worth consuming an extra line for every '{'; 1TBS's indentation is
enough for me to see the logical grouping, and matching braces is not
much of an issue now that we have editors that highlight matching pairs.
However, the difference becomes more clear once you add an "else":
if (allman)
{
foo;
}
else // maybe indented? I forget.
{
bar;
}
vs
if (1tbs) {
foo;
} else {
bar;
}
But, now that I'm thinking about it, I realize there's another subtle
difference: what you see at the _end_ of every line. In C, most lines
will end in ';', and if a line doesn't, it should have some other
character that indicates why not.
For instance, rather than this:
some long expression that
+ takes two lines;
I would write this:
some long expression that +
takes two lines;
The '+' at the end of the first line serves as a reminder why there is
no ';' there.
Similarly, putting the '{' at the end of the if/else lines shows why
there is no ';' there, rather than putting it on the next line.
Also, in rare cases where it makes sense, I have no objection to putting
it all on one line:
if (foo) bar;
or even:
if (foo) { bar; baz; }
If bar (and baz) are too long for this, then you have to move them to
following lines--but that's no reason to move the '{' as well.
And, if you're wondering why I'll give the '}' its own line, that's
because it's too easy to forget to move it if you add or remove a
statement to the end of said block when it's multi-line:
if (foo) {
bar;
baz; } // former end of block
quux; } // new end of block
Plus, that's just ugly!
Also, the '}' only gets its own line if it's not followed by an "else"
(as above) or a "while":
do {
foo;
bar;
} while (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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-12 08:15 -0700 |
| Message-ID | <87k2wdg73u.fsf@kst-u.example.com> |
| In reply to | #61876 |
Stephen Sprunk <stephen@sprunk.org> writes:
[...]
> However, the difference becomes more clear once you add an "else":
>
> if (allman)
> {
> foo;
> }
> else // maybe indented? I forget.
> {
> bar;
> }
>
> vs
>
> if (1tbs) {
> foo;
> } else {
> bar;
> }
My own preference for the latter is:
if (1tbs) {
foo;
}
else {
bar;
}
[...]
> Also, the '}' only gets its own line if it's not followed by an "else"
> (as above) or a "while":
>
> do {
> foo;
> bar;
> } while (baz);
I also put the "while" of a "do-while" on the same line as the "}";
otherwise it looks too much like an ordinary "while". Though I think I
did something like:
do {
...
}
while (cond); {
...
}
for an IOCCC entry.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-12 16:38 +0100 |
| Message-ID | <mit6nm$303$1@dont-email.me> |
| In reply to | #61903 |
On 12/05/15 16:15, Keith Thompson wrote:
<snip>
> I also put the "while" of a "do-while" on the same line as the "}";
> otherwise it looks too much like an ordinary "while".
When I was first learning C, someone else on the course - entirely by
accident - came up with the while-while loop. Something like this:
while(i--)
{
dosomethingwith(i, j);
dosomethingelsewith(i, j);
/* lots more code */
} while(i--);
Clearly he'd started out with a while, but by the time he'd got through
a few dozen lines of code, he'd forgotten this and assumed he'd started
out with a do. Obviously the code caused problems, so he looked more
closely. When he finally realised that he'd invented a new kind of loop,
he had the good sense to wonder why on earth it had compiled, and
started asking questions of the course tutor. It took a while[1] for him
to work out what was going on.
[1] Yes, I know.
--
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-12 11:38 -0500 |
| Message-ID | <mita80$h97$1@dont-email.me> |
| In reply to | #61907 |
On 12-May-15 10:38, Richard Heathfield wrote: > When I was first learning C, someone else on the course - entirely by > accident - came up with the while-while loop. ... When he finally > realised that he'd invented a new kind of loop, he had the good sense > to wonder why on earth it had compiled, and started asking questions > of the course tutor. It took a while[1] for him to work out what was > going on. I think I can guess what the compiler did with it, and why, but what was the actual result? 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-12 17:58 +0100 |
| Message-ID | <mitbdg$lor$1@dont-email.me> |
| In reply to | #61910 |
On 12/05/15 17:38, Stephen Sprunk wrote: > On 12-May-15 10:38, Richard Heathfield wrote: >> When I was first learning C, someone else on the course - entirely by >> accident - came up with the while-while loop. ... When he finally >> realised that he'd invented a new kind of loop, he had the good sense >> to wonder why on earth it had compiled, and started asking questions >> of the course tutor. It took a while[1] for him to work out what was >> going on. > > I think I can guess what the compiler did with it, and why, but what was > the actual result? On the systems du jour et du place, int was 16 bits, so the second loop (for there are, of course, two loops, the second of which is empty) just whizzed quietly along, wrapping the int from INT_MIN to INT_MAX half-way through[1] and, in due course, achieving its termination condition in a reasonably short time, whereupon the program continued quietly on its way. The end value of i, of course, was unaffected by the second loop: it's -1 whether or not the second loop is present. So, when he was running the program 'straight', there were no symptoms! The reason it caused problems was that he was chasing down an unrelated bug by stepping through the code in Turbo C's rather-good-for-the-time debugger, and when the first loop was done, the debugger just stayed on the second while(), seemingly forever - i.e. past the point of his patience - and that's how the rather odd construct first came to his attention. [1] No nasal demons were observed at that point, but they may just be biding their time. -- 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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-12 13:44 -0500 |
| Message-ID | <mithjq$g90$1@dont-email.me> |
| In reply to | #61911 |
On 12-May-15 11:58, Richard Heathfield wrote: > On 12/05/15 17:38, Stephen Sprunk wrote: >> On 12-May-15 10:38, Richard Heathfield wrote: >>> When I was first learning C, someone else on the course - >>> entirely by accident - came up with the while-while loop. ... >>> When he finally realised that he'd invented a new kind of loop, >>> he had the good sense to wonder why on earth it had compiled, and >>> started asking questions of the course tutor. It took a while[1] >>> for him to work out what was going on. >> >> I think I can guess what the compiler did with it, and why, but >> what was the actual result? > > On the systems du jour et du place, int was 16 bits, so the second > loop (for there are, of course, two loops, the second of which is > empty) Doh! I didn't realize that's how it'd be parsed, so my expectation was completely incorrect. I'm glad I asked. I had figured it'd apply the while condition at both the start and the end of one loop; I realize now that makes no sense at all, and I can only blame it on insufficient caffeine this morning. > [1] No nasal demons were observed at that point, but they may just > be biding their time. Those are the worst kind. 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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-12 11:32 -0500 |
| Message-ID | <mit9st$fur$1@dont-email.me> |
| In reply to | #61903 |
On 12-May-15 10:15, Keith Thompson wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
>> if (1tbs) {
>> foo;
>> } else {
>> bar;
>> }
>
> My own preference for the latter is:
>
> if (1tbs) {
> foo;
> }
> else {
> bar;
> }
Snatching defeat from the jaws of victory...
The "else" clause is logically bound to the "if" clause, so there's no
reason to start a new line, even though there's an intervening block.
> I also put the "while" of a "do-while" on the same line as the "}";
> otherwise it looks too much like an ordinary "while". Though I think I
> did something like:
>
> do {
> ...
> }
>
> while (cond); {
> ...
> }
>
> for an IOCCC entry.
The IOCCC is obviously a different matter entirely, since the goal is to
make it as difficult as possible to understand the code--or as easy as
possible to _mis_understand the code.
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-12 11:14 -0700 |
| Message-ID | <87twvhek8e.fsf@kst-u.example.com> |
| In reply to | #61909 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 12-May-15 10:15, Keith Thompson wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>> if (1tbs) {
>>> foo;
>>> } else {
>>> bar;
>>> }
>>
>> My own preference for the latter is:
>>
>> if (1tbs) {
>> foo;
>> }
>> else {
>> bar;
>> }
>
> Snatching defeat from the jaws of victory...
>
> The "else" clause is logically bound to the "if" clause, so there's no
> reason to start a new line, even though there's an intervening block.
There's a perfectly good reason. I like it.
It's also a fairly common style.
[...]
--
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-05-21 03:27 -0700 |
| Message-ID | <kfnwq029qf8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61903 |
Keith Thompson <kst-u@mib.org> writes:
> Stephen Sprunk <stephen@sprunk.org> writes:
> [...]
>> However, the difference becomes more clear once you add an "else":
>>
>> if (allman)
>> {
>> foo;
>> }
>> else // maybe indented? I forget.
>> {
>> bar;
>> }
>>
>> vs
>>
>> if (1tbs) {
>> foo;
>> } else {
>> bar;
>> }
>
> My own preference for the latter is:
>
> if (1tbs) {
> foo;
> }
> else {
> bar;
> }
>
> [...]
If you're interested this is (included as one rule in what is)
sometimes called Stroustrup style:
https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup
I have never understood the motiviation for this variation.
Can you explain why you prefer it over
if (1tbs) {
foo;
} else {
bar;
}
or
if (1tbs) {
foo;
} else {
bar;
}
etc?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-21 08:41 -0700 |
| Message-ID | <87oaleszst.fsf@kst-u.example.com> |
| In reply to | #62396 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> My own preference for the latter is:
>>
>> if (1tbs) {
>> foo;
>> }
>> else {
>> bar;
>> }
>>
>> [...]
>
> If you're interested this is (included as one rule in what is)
> sometimes called Stroustrup style:
>
> https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup
>
> I have never understood the motiviation for this variation.
> Can you explain why you prefer it over
>
> if (1tbs) {
> foo;
> } else {
> bar;
> }
>
> or
>
> if (1tbs) {
> foo;
>
> } else {
> bar;
> }
>
> etc?
Mostly it's what I'm used to.
I first learned C from K&R1, which puts "} else {" on a single line.
I don't know where I picked up the habit of writing
}
else {
rather than
} else {
I can rationalize that Stroustrup style is more consistent.
An opening "{" almost always appears at the end of a line, and a
closing "}" is almost always on a line by itself, aligned under
the corresponding "{" or keyword. With the "cuddled else" style,
"{" appears by itself *unless* it happens to be followed by "else".
--
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-05-24 18:12 -0700 |
| Message-ID | <kfn1ti5794h.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62409 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> My own preference for the latter is:
>>>
>>> if (1tbs) {
>>> foo;
>>> }
>>> else {
>>> bar;
>>> }
>>>
>>> [...]
>>
>> If you're interested this is (included as one rule in what is)
>> sometimes called Stroustrup style:
>>
>> https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup
>>
>> I have never understood the motiviation for this variation.
>> Can you explain why you prefer it over
>>
>> if (1tbs) {
>> foo;
>> } else {
>> bar;
>> }
>>
>> or
>>
>> if (1tbs) {
>> foo;
>>
>> } else {
>> bar;
>> }
>>
>> etc?
>
> Mostly it's what I'm used to.
>
> I first learned C from K&R1, which puts "} else {" on a single
> line. I don't know where I picked up the habit of writing
>
> }
> else {
>
> rather than
>
> } else {
>
> I can rationalize that Stroustrup style is more consistent. An
> opening "{" almost always appears at the end of a line, and a
> closing "}" is almost always on a line by itself, aligned under
> the corresponding "{" or keyword. With the "cuddled else" style,
> "{" appears by itself *unless* it happens to be followed by
> "else".
Presumably you meant "}" (close brace) in that last line there,
rather than open brace.
I don't see why you say it is more consistent. I expect you
write anonymous struct declarations (when you write them at all,
which is probably only rarely, but that doesn't change the
point), something like this example:
typedef struct {
...
} months[12], *p_month;
and do ... while() like this:
do {
...
} while (test_goes_here);
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 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? 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?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-24 19:20 -0700 |
| Message-ID | <87sialo0t2.fsf@kst-u.example.com> |
| In reply to | #62571 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>
>> [...]
>>
>>>> My own preference for the latter is:
>>>>
>>>> if (1tbs) {
>>>> foo;
>>>> }
>>>> else {
>>>> bar;
>>>> }
>>>>
>>>> [...]
>>>
>>> If you're interested this is (included as one rule in what is)
>>> sometimes called Stroustrup style:
>>>
>>> https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup
>>>
>>> I have never understood the motiviation for this variation.
>>> Can you explain why you prefer it over
>>>
>>> if (1tbs) {
>>> foo;
>>> } else {
>>> bar;
>>> }
>>>
>>> or
>>>
>>> if (1tbs) {
>>> foo;
>>>
>>> } else {
>>> bar;
>>> }
>>>
>>> etc?
>>
>> Mostly it's what I'm used to.
>>
>> I first learned C from K&R1, which puts "} else {" on a single
>> line. I don't know where I picked up the habit of writing
>>
>> }
>> else {
>>
>> rather than
>>
>> } else {
>>
>> I can rationalize that Stroustrup style is more consistent. An
>> opening "{" almost always appears at the end of a line, and a
>> closing "}" is almost always on a line by itself, aligned under
>> the corresponding "{" or keyword. With the "cuddled else" style,
>> "{" appears by itself *unless* it happens to be followed by
>> "else".
>
> Presumably you meant "}" (close brace) in that last line there,
> rather than open brace.
Yes.
> I don't see why you say it is more consistent. I expect you
> write anonymous struct declarations (when you write them at all,
> which is probably only rarely, but that doesn't change the
> point), something like this example:
>
> typedef struct {
> ...
> } months[12], *p_month;
I probably wouldn't write that, but yes, if I did that's how I'd format
it.
> and do ... while() like this:
>
> do {
> ...
> } while (test_goes_here);
Yes -- partly because if the while is on the next line it looks like the
beginning of a while loop. (I've been known to do it for the sake of
deliberate obfuscation).
> 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.
--
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-10 08:51 -0700 |
| Message-ID | <kfnegkg6meq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62575 |
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:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>> [...]
>>>
>>>>> My own preference for the latter is:
>>>>>
>>>>> if (1tbs) {
>>>>> foo;
>>>>> }
>>>>> else {
>>>>> bar;
>>>>> }
>>>>>
>>>>> [...]
>>>>
>>>> If you're interested this is (included as one rule in what is)
>>>> sometimes called Stroustrup style:
>>>>
>>>> https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup
>>>>
>>>> I have never understood the motiviation for this variation.
>>>> Can you explain why you prefer it over
>>>>
>>>> if (1tbs) {
>>>> foo;
>>>> } else {
>>>> bar;
>>>> }
>>>>
>>>> or
>>>>
>>>> if (1tbs) {
>>>> foo;
>>>>
>>>> } else {
>>>> bar;
>>>> }
>>>>
>>>> etc?
>>>
>>> Mostly it's what I'm used to.
>>>
>>> I first learned C from K&R1, which puts "} else {" on a single
>>> line. I don't know where I picked up the habit of writing
>>>
>>> }
>>> else {
>>>
>>> rather than
>>>
>>> } else {
>>>
>>> I can rationalize that Stroustrup style is more consistent. An
>>> opening "{" almost always appears at the end of a line, and a
>>> closing "}" is almost always on a line by itself, aligned under
>>> the corresponding "{" or keyword. With the "cuddled else" style,
>>> "{" appears by itself *unless* it happens to be followed by
>>> "else".
>>
>> Presumably you meant "}" (close brace) in that last line there,
>> rather than open brace.
>
> Yes.
>
>> I don't see why you say it is more consistent. I expect you
>> write anonymous struct declarations (when you write them at all,
>> which is probably only rarely, but that doesn't change the
>> point), something like this example:
>>
>> typedef struct {
>> ...
>> } months[12], *p_month;
>
> I probably wouldn't write that, but yes, if I did that's how I'd format
> it.
>
>> and do ... while() like this:
>>
>> do {
>> ...
>> } while (test_goes_here);
>
> Yes -- partly because if the while is on the next line it looks like the
> beginning of a while loop. (I've been known to do it for the sake of
> deliberate obfuscation).
>
>> 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 11:35 -0700 |
| Message-ID | <lna8v3svwd.fsf@kst-u.example.com> |
| In reply to | #65123 |
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;
}
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.
No doubt there are valid counterarguments, and I'm not going to object
to anyone else using a different layout (within reason).
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.)
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-10 14:54 -0400 |
| Message-ID | <55A014FA.3060003@verizon.net> |
| In reply to | #65169 |
On 07/10/2015 02:40 PM, Stefan Ram wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> Context: I prefer
>> if (condition) {
>> statement;
>> }
>
> Why do you put the semicolon »;« behind the statement?
That seems an extremely conventional usage. Have you seen it done
differently? If so, could you give an example?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-10 15:10 -0400 |
| Message-ID | <55A01899.1000406@verizon.net> |
| In reply to | #65172 |
On 07/10/2015 02:54 PM, James Kuyper wrote:
> On 07/10/2015 02:40 PM, Stefan Ram wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Context: I prefer
>>> if (condition) {
>>> statement;
>>> }
>>
>> Why do you put the semicolon »;« behind the statement?
>
> That seems an extremely conventional usage. Have you seen it done
> differently? If so, could you give an example?
Sorry - I just figured it out. The ';' at the end of
Expression-statements and jump-statements is part of the statement, not
a separate element. None of the other statement types end with ';'.
Either way, a ';' after a statement is a redundant null-statement.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-10 20:51 +0000 |
| Message-ID | <mnpb92$5vk$1@speranza.aioe.org> |
| In reply to | #65178 |
James Kuyper <jameskuyper@verizon.net> wrote:
> On 07/10/2015 02:54 PM, James Kuyper wrote:
>> On 07/10/2015 02:40 PM, Stefan Ram wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Context: I prefer
>>>> if (condition) {
>>>> statement;
>>>> }
>>> Why do you put the semicolon »;« behind the statement?
>> That seems an extremely conventional usage. Have you seen it done
>> differently? If so, could you give an example?
> Sorry - I just figured it out. The ';' at the end of
> Expression-statements and jump-statements is part of the statement, not
> a separate element. None of the other statement types end with ';'.
> Either way, a ';' after a statement is a redundant null-statement.
If written in BNF form, or other abstract notation, I think
I would agree.
But note that both condition and statement are legal C variable
names, such that the syntax is legal. I might write:
if( <condition> ) <statement>
where <statement> would include the terminating semicolon.
The question is, what is more readable as a newsgroup post.
Pascal users will be very confused by the discussion.
-- glen
[toc] | [prev] | [next] | [standalone]
Page 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web