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 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-12 17:28 +1200 |
| Message-ID | <crdhb0Ff3c5U1@mid.individual.net> |
| In reply to | #61858 |
Bartc wrote:
> On 11/05/2015 20:04, Richard Heathfield wrote:
>> On 11/05/15 19:47, Stephen Sprunk wrote:
>
>>> Well, it's called 1TBS for a reason :)
>
>> In the following:
>>
>> int foo(parms)
>> {
>> first indent level;
>> if(more)
>> {
>> second indent level;
>> }
>> return bar;
>> }
>
> That's too spread out, especially with the extra line between the 'if'
> and the statements in the True branch.
Why is it "too spread out"?
Richard's (and coincidentally, my) style might have been a problem when
we were using 24x80 displays, but on a decent contemporary display were
I have 80+ lines visible (even allowing for IDE clutter), there's no
need to squidge up code.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-12 11:09 +0100 |
| Message-ID | <misjfb$l6u$1@dont-email.me> |
| In reply to | #61882 |
On 12/05/2015 06:28, Ian Collins wrote:
> Bartc wrote:
>> On 11/05/2015 20:04, Richard Heathfield wrote:
>>> On 11/05/15 19:47, Stephen Sprunk wrote:
>>
>>>> Well, it's called 1TBS for a reason :)
>>
>>> In the following:
>>>
>>> int foo(parms)
>>> {
>>> first indent level;
>>> if(more)
>>> {
>>> second indent level;
>>> }
>>> return bar;
>>> }
>>
>> That's too spread out, especially with the extra line between the 'if'
>> and the statements in the True branch.
>
> Why is it "too spread out"?
>
> Richard's (and coincidentally, my) style might have been a problem when
> we were using 24x80 displays, but on a decent contemporary display were
> I have 80+ lines visible (even allowing for IDE clutter), there's no
> need to squidge up code.
It's not a question of being able to fit as much as possible on a
screen. It's about being able to see things at a glance more easily and
also giving the correct 'shape' to the code. And not having to navigate
up and down so much. The above style I guess would extend to:
if (cond1)
{
one;
two;
}
else if (cond2)
{
three;
four;
}
else
{
four;
five;
}
Syntaxes that use, for example, 'then' and 'end if' manage to a achieve
a solid squarish profile of the block structure.
This is more difficult to achieve using { and } but the above style must
be the worst (other than inserting even more blank lines).
Also, while the above doesn't look /that/ terrible in my newsreader
font, try seeing it where extra inter-line spacing has been added (in a
Pastebin code window for example). Then that 'three' statement seems a
very long way from its enabling condition! It gets worse with bigger tabs:
if (cond1)
{
one;
two;
}
Just moving each { to the end of the previous line (with a preceding
space obviously) would be a big help.
--
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-12 11:43 +0100 |
| Message-ID | <mislev$sr1$1@dont-email.me> |
| In reply to | #61890 |
On 12/05/2015 11:09, Bartc wrote:
> On 12/05/2015 06:28, Ian Collins wrote:
>> Richard's (and coincidentally, my) style might have been a problem when
>> we were using 24x80 displays, but on a decent contemporary display were
>> I have 80+ lines visible (even allowing for IDE clutter), there's no
>> need to squidge up code.
> Also, while the above doesn't look /that/ terrible in my newsreader
> font, try seeing it where extra inter-line spacing has been added (in a
> Pastebin code window for example). Then that 'three' statement seems a
> very long way from its enabling condition! It gets worse with bigger tabs:
>
> if (cond1)
> {
> one;
> two;
> }
I've just changed one of my C code-generators to use this style (also
with else/else if on lines by themselves.
I have to admit that on a large scale, it does look quite pleasing, with
the symmetrically placed braces. Even though it did require 10% more
lines and many bits of code did look more lonely.
(However, I don't need to write the code myself. Nor actually need to
see it except when sorting out problems.)
(This highlighted another little quirk of C's that is now more obvious:
the sequence of statements between a case-label and the next case (or
default label) doesn't need to be enclosed in a {...} block. I know the
reasons but it still looks odd.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-05-12 05:16 -0700 |
| Message-ID | <1c1c98ab-eb88-4bb5-8ca9-4ea728505634@googlegroups.com> |
| In reply to | #61890 |
Bart wrote:"
if (cond1)
{
one;
two;
}
else if (cond2)
{
three;
four;
}
else
{
four;
five;
}"
if(cond1){ one; two; }
else if(cond2){ three; four; }
else { four; five; }
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-05-12 05:34 -0700 |
| Message-ID | <9a9916a3-e09c-44eb-8888-5d20fbe92cc2@googlegroups.com> |
| In reply to | #61896 |
G(!cond1,l1);ist1; ist2; G(1,l3); l1: G(!cond1,l2);ist3; ist4; G(1,l3); l2: G(!cond1,l3);ist5; ist6; G(1,l3); l3:
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-12 22:52 +0100 |
| Message-ID | <mitsl2$ru3$1@dont-email.me> |
| In reply to | #61896 |
On 12/05/2015 13:16, asetofsymbols@gmail.com wrote:
> Bart wrote:"
> if (cond1)
> {
> one;
> two;
> }
> else if (cond2)
> {
> three;
> four;
> }
> else
> {
> four;
> five;
> }"
>
> if(cond1){ one; two; }
> else if(cond2){ three; four; }
> else { four; five; }
>
That doesn't look too bad, especially if there exists some
correspondence between statements in each columns (although it should be
'five; six;' on the last line).
On 12/05/2015 13:34, asetofsymbols@gmail.com wrote:
> G(!cond1,l1);ist1; ist2; G(1,l3);
> l1: G(!cond1,l2);ist3; ist4; G(1,l3);
> l2: G(!cond1,l3);ist5; ist6; G(1,l3);
> l3:
Unlike this, even after fixing this up to match the one above:
G(!cond1,l1);one; two; G(1,l3);
l1: G(!cond2,l2);three; four; G(1,l3);
l2: five; six;
l3:
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-21 03:45 -0700 |
| Message-ID | <kfnsiaq9pkt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61882 |
Ian Collins <ian-news@hotmail.com> writes:
> Bartc wrote:
>> On 11/05/2015 20:04, Richard Heathfield wrote:
>>> On 11/05/15 19:47, Stephen Sprunk wrote:
>>>
>>>> Well, it's called 1TBS for a reason :)
>>>
>>> In the following:
>>>
>>> int foo(parms)
>>> {
>>> first indent level;
>>> if(more)
>>> {
>>> second indent level;
>>> }
>>> return bar;
>>> }
>>
>> That's too spread out, especially with the extra line between the
>> 'if' and the statements in the True branch.
>
> Why is it "too spread out"?
>
> Richard's (and coincidentally, my) style might have been a problem
> when we were using 24x80 displays, but on a decent contemporary
> display were I have 80+ lines visible (even allowing for IDE
> clutter), there's no need to squidge up code.
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?
If the answer is (a) or (b), what is (are) the benefit(s) that
motivate this choice rather than sticking with the more
traditional one? (Incidentally, my measurements show code
written using Allman style take about 9 or 10 percent more
lines than they would if written using 1TBS.)
If the answer is (c), why not write this?
first indent level;
if (more) {
second indent level;
}
return bar;
I guess the point of my question is can you explain what the
various aspects are that lead you to prefer putting the open
brace on a line by itself (ie, other than just a circular
reason like "it's more logical" or "it's easier to read")?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-21 12:53 +0100 |
| Message-ID | <mjkgtm$aun$1@dont-email.me> |
| In reply to | #62397 |
On 21/05/15 11:45, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
<snip>
[Allman style]
>> Why is it "too spread out"?
>>
>> Richard's (and coincidentally, my) style might have been a problem
>> when we were using 24x80 displays, but on a decent contemporary
>> display were I have 80+ lines visible (even allowing for IDE
>> clutter), there's no need to squidge up code.
>
> 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?
>
> If the answer is (a) or (b), what is (are) the benefit(s) that
> motivate this choice rather than sticking with the more
> traditional one? (Incidentally, my measurements show code
> written using Allman style take about 9 or 10 percent more
> lines than they would if written using 1TBS.)
The benefit comes from two consequences of the style choice: (1) the
opening brace and closing brace of a block are in the same column (which
is good for reasons that I believe I've already mentioned), and (2) you
get a bit of wind between the busyness of the construct's header and the
relatively calm lagoon between the braces. Less poetically, whitespace
is helpful for those who
havedifficultyinreadingstuffthatisallcrammedtogether, and this brace is
almost as good at that as a blank line, without actually being a blank line.
I have a tendency to add a blank line /before/ an if, for, while, etc as
well. Blank lines is good (up to a point).
> If the answer is (c), why not write this?
>
> first indent level;
> if (more) {
>
> second indent level;
> }
> return bar;
>
> I guess the point of my question is can you explain what the
> various aspects are that lead you to prefer putting the open
> brace on a line by itself (ie, other than just a circular
> reason like "it's more logical" or "it's easier to read")?
It /is/ more logical, and it /is/ easier to read, but these are not
circular reasons. It is more logical and easier to read because of the
strong linear association between the construct's header, the opening
brace, and a closing brace. They are all in a nice neat uninterrupted
straight line, and the enclosed block of code is within them (and
slightly to their right), so it's obvious what belongs with what and
what belongs to what.
--
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 | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-05-21 11:01 -0700 |
| Message-ID | <341dfded-0c3c-460e-8b12-5b6d0837e505@googlegroups.com> |
| In reply to | #62398 |
Stefan wrote:"
from Kernighan's B tutorial from 1972:
if(---)
{ -----
----- }
else if(---)
{ -----
----- }
else if(----)
{ -----
----- }
from en.wikipedia.org/wiki/Indent_style (under pico):
stuff(n):
{ x: 3 * n;
y: doStuff(x);
y + x }"
I find more easy this
if(z){ x: 3 * n;
y: doStuff(x);
y + x
}
x: 3 * n;
y: doStuff(x);
y + x
Because if one parenthesis open
and want find where close
search down in the same line
and separate blocks with a blank line
(the one has '}')
I have as the impression that
would be all ok using only
indentation and no parenthesis at all
There is a language that use
indentation as parenthesis in C
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-21 20:18 +0100 |
| Message-ID | <878uchloxo.fsf@bsb.me.uk> |
| In reply to | #62398 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
<snip>
> from Kernighan's B tutorial from 1972:
>
> if(---)
> { -----
> ----- }
> else if(---)
> { -----
> ----- }
> else if(----)
> { -----
> ----- }
Just keep the record straight, that's not an example of how Kernighan
indents B code -- it's given as an example of a logical structure. In
all the code fragments of the tutorial, Kernighan uses the
if (a<b) {
t = a;
a = b;
b = t;
}
style.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-21 21:47 +0100 |
| Message-ID | <87r3q9k68r.fsf@bsb.me.uk> |
| In reply to | #62427 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>><snip>
>>> from Kernighan's B tutorial from 1972:
>>>
>>> if(---)
>>> { -----
>>> ----- }
>>> else if(---)
>>> { -----
>>> ----- }
>>> else if(----)
>>> { -----
>>> ----- }
>>Just keep the record straight, that's not an example of how Kernighan
>>indents B code -- it's given as an example of a logical structure. In
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>>all the code fragments of the tutorial, Kernighan uses the
>> if (a<b) {
>> t = a;
>> a = b;
>> b = t;
>> }
>>style.
>
> If Kernighan believes that the »if(---)«-formatting (that is
> shown above) shows the logical structure the best, than this
> might be a reason to think about whether this formatting
> should be used generally to format source code.
Maybe I did not express myself well. He wrote what you quoted in the
same way I might write "you can always make a big if-else statement like
this: if (...) {...} else if (...) {...} else {...}". There is no
suggestion that this is how I like to format my code, and there is none
(indeed there is evidence to the contrary) that Kernighan like to format
his code as you quoted. This is not the impression youe quote gave so I
wanted to correct it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kusalananda <kusalananda@example.com> |
|---|---|
| Date | 2015-05-24 07:12 +0000 |
| Message-ID | <slrnmm2u5v.ono.kusalananda@macbook-air.local> |
| In reply to | #62398 |
On 2015-05-23, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
[cut]
> But it is easier to see here, because now it's closer to the "if".
>
> if( self )
> { /* if multiplicity is 0 then unlink and dispose the node */
> if( !self->multiplicity )
> { if( previous ){ previous->next = self->next; } /* unlink this from list */
> else { base->first = self->next; } /* unlink this from list */
> base->free( self ); /* dispose this node */ }}
> else base->error = 2; /* no memory for node */
>
> Also, when less vertical space is wasted, it is less often necessary
> to turn pages in a book (and it is really difficult to compare depth
> of alignment across different pages!) or to scroll code in an editor
> window (it's also difficult to compare depth, when two lines cannot
> be seen together on one screen).
Hmmm... I ran your code through a indentation program (clang-format),
which I often do with smaller pieces code that I need to get to know:
if (self) {/* if multiplicity is 0 then unlink and dispose the node */
if (!self->multiplicity) {
if (previous) {
previous->next = self->next;
} /* unlink this from list */
else {
base->first = self->next;
} /* unlink this from list */
base->free(self); /* dispose this node */
}
}
else
base->error = 2; /* no memory for node */
I'm not going to complain too much about your preference for vertical
compactness, which I find a bit absurd. Instead I noticed that your
comment block lies outside of (and after) the {}-blocks that they
comment upon. This is extra clear from the re-indented code above.
Personally (and I don't want to sound like I know best, because this
is just personal preferences after all), I want my comments to tell me
what's coming, except for one-line statements (and I disallow one-line
{}-blocks):
if (self) {
/* if multiplicity is 0 then unlink and dispose the node */
if (!self->multiplicity) {
if (previous) {
/* unlink this from list */
previous->next = self->next;
}
else {
/* unlink this from list */
base->first = self->next;
}
base->free(self); /* dispose this node */
}
}
else {
/* no memory for node */
base->error = 2;
}
Alternatively, removing the superfluous braces and instead relying on
whitespace to tell the story about the internal if-else structure:
if (self) {
/* if multiplicity is 0 then unlink and dispose the node */
if (!self->multiplicity) {
if (previous)
previous->next = self->next; /* unlink this from list */
else
base->first = self->next; /* unlink this from list */
base->free(self); /* dispose this node */
}
}
else
base->error = 2; /* no memory for node */
--
:: Andreas Kusalananda Kahari, Uppsala University, Sweden ::
:: a n d r e a s . k a h a r i @ i c m . u u . s e ::
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 08:59 -0700 |
| Message-ID | <kfn615s6m0x.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62398 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> { ++x;
>> ++x; }
>
> I have made a minor new observation that might explain
> why I like to save vertical space:
>
> First, let me describe what this means:
>
> I like to save vertical space. That is, I prefer
>
> { ++x;
> ++x; }
>
> or even
>
> { ++x; ++x; }
>
> to
>
> {
> ++x;
> ++x;
> }
>
> or even
>
> {
>
> ++x;
> ++x;
>
> }
>
> But why?
>
> When one tries to understand a piece of code, sometimes
> it helps to observe, whether the indentation of two line
> is the same. And this is easier, when they are more close
> to each other! So it is easier when vertical space is saved.
> [snip elaboration]
Two comments. One, it's easy to see if indentation matches
just by using more spaces per level of nesting. Two, studies
have shown that not having close braces line up vertically
with their corresponding opening line results in greater
defect rates. So what you're suggesting is objectively
bad programming practice. To me this argument is very
much a tail-wagging-the-dog kind of reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 09:18 -0700 |
| Message-ID | <kfnsi8w56lj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62398 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 21/05/15 11:45, Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>
> <snip>
>
> [Allman style]
>
>>> Why is it "too spread out"?
>>>
>>> Richard's (and coincidentally, my) style might have been a problem
>>> when we were using 24x80 displays, but on a decent contemporary
>>> display were I have 80+ lines visible (even allowing for IDE
>>> clutter), there's no need to squidge up code.
>>
>> 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?
>>
>> If the answer is (a) or (b), what is (are) the benefit(s) that
>> motivate this choice rather than sticking with the more
>> traditional one? (Incidentally, my measurements show code
>> written using Allman style take about 9 or 10 percent more
>> lines than they would if written using 1TBS.)
>
> The benefit comes from two consequences of the style choice: (1) the
> opening brace and closing brace of a block are in the same column
> (which is good for reasons that I believe I've already mentioned), and
> (2) you get a bit of wind between the busyness of the construct's
> header and the relatively calm lagoon between the braces. Less
> poetically, whitespace is helpful for those who
> havedifficultyinreadingstuffthatisallcrammedtogether, and this brace
> is almost as good at that as a blank line, without actually being a
> blank line.
To me this comes across as "I like the way this is written,
because it's written in a way that I like." I think it would
help if you put more effort into just communicating, and less
into convincing/arguing.
> I have a tendency to add a blank line /before/ an if, for, while, etc
> as well. Blank lines is good (up to a point).
>
>> If the answer is (c), why not write this?
>>
>> first indent level;
>> if (more) {
>>
>> second indent level;
>> }
>> return bar;
>>
>> I guess the point of my question is can you explain what the
>> various aspects are that lead you to prefer putting the open
>> brace on a line by itself (ie, other than just a circular
>> reason like "it's more logical" or "it's easier to read")?
>
> It /is/ more logical, and it /is/ easier to read, but these are not
> circular reasons. It is more logical and easier to read because of the
> strong linear association between the construct's header, the opening
> brace, and a closing brace. They are all in a nice neat uninterrupted
> straight line, and the enclosed block of code is within them (and
> slightly to their right), so it's obvious what belongs with what and
> what belongs to what.
Again, this comes across as liking how it's written because it's
written in the way that you like. What are the forces that make
those things important to you? Obviously they are not important
to many other people.
(Sorry for the long delay in responding, life has been unusually
demanding of late.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-22 07:15 +1200 |
| Message-ID | <cs6p7aFf7cmU2@mid.individual.net> |
| In reply to | #62397 |
Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> Bartc wrote:
>>> On 11/05/2015 20:04, Richard Heathfield wrote:
>>>> On 11/05/15 19:47, Stephen Sprunk wrote:
>>>>
>>>>> Well, it's called 1TBS for a reason :)
>>>>
>>>> In the following:
>>>>
>>>> int foo(parms)
>>>> {
>>>> first indent level;
>>>> if(more)
>>>> {
>>>> second indent level;
>>>> }
>>>> return bar;
>>>> }
>>>
>>> That's too spread out, especially with the extra line between the
>>> 'if' and the statements in the True branch.
>>
>> Why is it "too spread out"?
>>
>> Richard's (and coincidentally, my) style might have been a problem
>> when we were using 24x80 displays, but on a decent contemporary
>> display were I have 80+ lines visible (even allowing for IDE
>> clutter), there's no need to squidge up code.
>
> 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.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 08:53 -0700 |
| Message-ID | <kfna8v46mb6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62426 |
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Bartc wrote:
>>>> On 11/05/2015 20:04, Richard Heathfield wrote:
>>>>> On 11/05/15 19:47, Stephen Sprunk wrote:
>>>>>
>>>>>> Well, it's called 1TBS for a reason :)
>>>>>
>>>>> In the following:
>>>>>
>>>>> int foo(parms)
>>>>> {
>>>>> first indent level;
>>>>> if(more)
>>>>> {
>>>>> second indent level;
>>>>> }
>>>>> return bar;
>>>>> }
>>>>
>>>> That's too spread out, especially with the extra line between the
>>>> 'if' and the statements in the True branch.
>>>
>>> Why is it "too spread out"?
>>>
>>> Richard's (and coincidentally, my) style might have been a problem
>>> when we were using 24x80 displays, but on a decent contemporary
>>> display were I have 80+ lines visible (even allowing for IDE
>>> clutter), there's no need to squidge up code.
>>
>> 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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-11 14:09 +1200 |
| Message-ID | <d0bc6uFegarU4@mid.individual.net> |
| In reply to | #65126 |
Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> Tim Rentsch wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>
>>>> Bartc wrote:
>>>>> On 11/05/2015 20:04, Richard Heathfield wrote:
>>>>>> On 11/05/15 19:47, Stephen Sprunk wrote:
>>>>>>
>>>>>>> Well, it's called 1TBS for a reason :)
>>>>>>
>>>>>> In the following:
>>>>>>
>>>>>> int foo(parms)
>>>>>> {
>>>>>> first indent level;
>>>>>> if(more)
>>>>>> {
>>>>>> second indent level;
>>>>>> }
>>>>>> return bar;
>>>>>> }
>>>>>
>>>>> That's too spread out, especially with the extra line between the
>>>>> 'if' and the statements in the True branch.
>>>>
>>>> Why is it "too spread out"?
>>>>
>>>> Richard's (and coincidentally, my) style might have been a problem
>>>> when we were using 24x80 displays, but on a decent contemporary
>>>> display were I have 80+ lines visible (even allowing for IDE
>>>> clutter), there's no need to squidge up code.
>>>
>>> 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).
Yes on a tiny screen the extra line may have a cost in terms of visible
code. On a decent screen (my current IDE window has 550 lines of
visible code!) to my eye it makes it easier to read.
Maybe I just like the symmetry of the opening and closing braces.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2015-07-11 10:37 +0800 |
| Message-ID | <mnpvff$7hh$1@dont-email.me> |
| In reply to | #65226 |
Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>>Maybe I just like the symmetry of the opening and closing braces.
>
> I understand that this must seem strange to some readers,
> but I deem »{« and »}« to be »indentation-changing« characters.
> »{« means »increase the indentation by 2«, while
> »}« means »decrease the indentation by 2«.
>
> So, I write:
>
> puts( "example" );
> puts( "example" );
> puts( "example" );
> {
> puts( "example" ); /* "{" has increased the indentation by 2 */
> puts( "example" );
> puts( "example" );
> }
> puts( "example" ); /* "}" has decreased the indentation by 2 */
> puts( "example" );
> puts( "example" );
>
> And so it just happens to be that the »}« is not directly below the »{«.
>
> I compare this to:
>
> puts( "example" );
> puts( "example" );
> puts( "example" );
> GOSUB BLOCK;
>
> puts( "example" );
> puts( "example" );
> puts( "example" );
> RETURN FROM BLOCK;
>
> puts( "example" );
> puts( "example" );
> puts( "example" );
>
> The »GOSUB« is still part of the main block,
> while the »RETURN« is still part of the subblock.
> So, »GOSUB« is indented with the main block,
> and »RETURN« is indented with the subblock.
>
> I compare »{« to »GOSUB« and »}« to »RETURN«.
>
> BASIC taught me all I need to know about computer programming!
That provokes a quote from Edsger W. Dijkstra: ;-)
"It is practically impossible to teach good programming to students that
have had a prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration."
--
Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 12:51 -0700 |
| Message-ID | <kfnbnfiwjzu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65226 |
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:
>>>>
>>>>> Bartc wrote:
>>>>>> On 11/05/2015 20:04, Richard Heathfield wrote:
>>>>>>> On 11/05/15 19:47, Stephen Sprunk wrote:
>>>>>>>
>>>>>>>> Well, it's called 1TBS for a reason :)
>>>>>>>
>>>>>>> In the following:
>>>>>>>
>>>>>>> int foo(parms)
>>>>>>> {
>>>>>>> first indent level;
>>>>>>> if(more)
>>>>>>> {
>>>>>>> second indent level;
>>>>>>> }
>>>>>>> return bar;
>>>>>>> }
>>>>>>
>>>>>> That's too spread out, especially with the extra line between the
>>>>>> 'if' and the statements in the True branch.
>>>>>
>>>>> Why is it "too spread out"?
>>>>>
>>>>> Richard's (and coincidentally, my) style might have been a problem
>>>>> when we were using 24x80 displays, but on a decent contemporary
>>>>> display were I have 80+ lines visible (even allowing for IDE
>>>>> clutter), there's no need to squidge up code.
>>>>
>>>> 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.
> 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.
> 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.
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).
> Maybe I just like the symmetry of the opening and closing braces.
This comment is actually quite helpful. Thank you for coming
back and responding again.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-12 10:20 +1200 |
| Message-ID | <d0dj54FegarU7@mid.individual.net> |
| In reply to | #65328 |
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! >> 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. >> 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. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web