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 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-07 13:36 -0700 |
| Message-ID | <kfn7fskgm6m.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61713 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> To summarize, I favor 'if( a == b )' over 'if (a==b)' because the >> first form takes less effort both physically and mentally, as >> detailed above. Make sense? > > Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same > reason. That's fine but you don't say what factors influence that. Can you say anything about what those are? Might it be that you find the first form easier just because that's what you are used to?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-07 15:09 -0700 |
| Message-ID | <87r3qshwej.fsf@kst-u.example.com> |
| In reply to | #61723 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>> To summarize, I favor 'if( a == b )' over 'if (a==b)' because the
>>> first form takes less effort both physically and mentally, as
>>> detailed above. Make sense?
>>
>> Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same
>> reason.
>
> That's fine but you don't say what factors influence that. Can
> you say anything about what those are?
Not a whole lot.
> Might it be that you
> find the first form easier just because that's what you are
> used to?
That's likely. I also have a vague preference for making things that
aren't function calls not look like function calls:
fn(a == b);
if (a == b) {
// ...
}
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-07 17:13 -0700 |
| Message-ID | <8a64b0b5-11e5-442d-a047-55da504299b1@googlegroups.com> |
| In reply to | #61729 |
On Thursday, May 7, 2015 at 11:10:07 PM UTC+1, Keith Thompson wrote:
>
> That's likely. I also have a vague preference for making things that
> aren't function calls not look like function calls:
>
> fn(a == b);
> if (a == b) {
> // ...
> }
>
Typically at the head of one on my files you'll see
#define lerp(a,b,t) ((a) +((b) -(a)) * (t))
#define clamp(x,low,high) ((x) < (low) ? (low) : (x) > (high) ? (high) : (x))
#define sign(x) ((x) > 0 ? 1 : (x) < 0 : -1 : 0)
I use those little macros all the time. They look like function calls.
You could write clamp to modify the x argument, but that wouldn't
be a good idea.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-07 18:07 -0700 |
| Message-ID | <87mw1fj2q8.fsf@kst-u.example.com> |
| In reply to | #61738 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, May 7, 2015 at 11:10:07 PM UTC+1, Keith Thompson wrote:
>> That's likely. I also have a vague preference for making things that
>> aren't function calls not look like function calls:
>>
>> fn(a == b);
>> if (a == b) {
>> // ...
>> }
>>
> Typically at the head of one on my files you'll see
>
> #define lerp(a,b,t) ((a) +((b) -(a)) * (t))
> #define clamp(x,low,high) ((x) < (low) ? (low) : (x) > (high) ? (high) : (x))
> #define sign(x) ((x) > 0 ? 1 : (x) < 0 : -1 : 0)
>
> I use those little macros all the time. They look like function calls.
> You could write clamp to modify the x argument, but that wouldn't
> be a good idea.
Sure, invocations of function-like macros should look like function
calls (that's the whole point). Except that most macros should
have all-caps names, unless they're meant to be direct replacements
for equivalent functions.
But if(), while(), return, sizeof, and so forth are not functions,
and I like to make a clear distinction.
I don't claim to be entirely consistent, and I don't have any great
trouble reading code that uses `if(cond)`, `sizeof(expr)`, or even
`return(value)`.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-08 11:35 +0200 |
| Message-ID | <mihvv6$2i0$1@dont-email.me> |
| In reply to | #61739 |
On 08/05/15 03:07, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Thursday, May 7, 2015 at 11:10:07 PM UTC+1, Keith Thompson wrote:
>>> That's likely. I also have a vague preference for making things that
>>> aren't function calls not look like function calls:
>>>
>>> fn(a == b);
>>> if (a == b) {
>>> // ...
>>> }
>>>
>> Typically at the head of one on my files you'll see
>>
>> #define lerp(a,b,t) ((a) +((b) -(a)) * (t))
>> #define clamp(x,low,high) ((x) < (low) ? (low) : (x) > (high) ? (high) : (x))
>> #define sign(x) ((x) > 0 ? 1 : (x) < 0 : -1 : 0)
>>
>> I use those little macros all the time. They look like function calls.
>> You could write clamp to modify the x argument, but that wouldn't
>> be a good idea.
>
> Sure, invocations of function-like macros should look like function
> calls (that's the whole point). Except that most macros should
> have all-caps names, unless they're meant to be direct replacements
> for equivalent functions.
I prefer my function-like macros to have small-caps names - they are
function-like, and so I like them to look like functions.
Of course, where possible I would replace function-like macros with
static inline functions:
static inline double lerp(double a, double b, double t) {
return a + (b - a) * t;
}
That might be a problem with "sign" if it has to handle different types
efficiently (though the compiler might be able to optimise even if the
parameter was forced into a double). Perhaps _Generic combined with
static inlines is the best choice here.
>
> But if(), while(), return, sizeof, and so forth are not functions,
> and I like to make a clear distinction.
>
> I don't claim to be entirely consistent, and I don't have any great
> trouble reading code that uses `if(cond)`, `sizeof(expr)`, or even
> `return(value)`.
>
I /do/ claim to be consistent, at least in the code I write entirely
myself, but my consistent behaviour is slightly different - I have a
space after "if", "while", "return", etc., but no space after "sizeof".
To me, sizeof looks more like a function and not a control-flow keyword
(and yes, I know it is an operator and is not a function). The same
applies to _Alignof / alignof.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-11 11:41 -0700 |
| Message-ID | <kfn7fsfdkib.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61757 |
David Brown <david.brown@hesbynett.no> writes:
> On 08/05/15 03:07, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> On Thursday, May 7, 2015 at 11:10:07 PM UTC+1, Keith Thompson wrote:
>>>> That's likely. I also have a vague preference for making things that
>>>> aren't function calls not look like function calls:
>>>>
>>>> fn(a == b);
>>>> if (a == b) {
>>>> // ...
>>>> }
>>>
>>> Typically at the head of one on my files you'll see
>>>
>>> #define lerp(a,b,t) ((a) +((b) -(a)) * (t))
>>> #define clamp(x,low,high) ((x) < (low) ? (low) : (x) > (high) ? (high) : (x))
>>> #define sign(x) ((x) > 0 ? 1 : (x) < 0 : -1 : 0)
>>>
>>> I use those little macros all the time. They look like function calls.
>>> You could write clamp to modify the x argument, but that wouldn't
>>> be a good idea.
>>
>> Sure, invocations of function-like macros should look like function
>> calls (that's the whole point). Except that most macros should
>> have all-caps names, unless they're meant to be direct replacements
>> for equivalent functions.
>
> I prefer my function-like macros to have small-caps names - they
> are function-like, and so I like them to look like functions.
Note that 'function-like macro' has a technical meaning in the
context of the ISO C standard, and that is probably not what you
mean in the comment above. (As the standard uses the term,
a 'function-like macro' is any macro with parameters, not just
those macros that can be used like a function call.)
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-11 13:59 -0500 |
| Message-ID | <miqu3p$a3m$1@dont-email.me> |
| In reply to | #61757 |
On 08-May-15 04:35, David Brown wrote: > On 08/05/15 03:07, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> Typically at the head of one on my files you'll see >>> >>> #define lerp(a,b,t) ((a) +((b) -(a)) * (t)) >>> #define clamp(x,low,high) ((x) < (low) ? (low) : (x) > (high)\ >>> ? (high) : (x)) >>> #define sign(x) ((x) > 0 ? 1 : (x) < 0 : -1 : 0) >>> >>> I use those little macros all the time. They look like function >>> calls. You could write clamp to modify the x argument, but that >>> wouldn't be a good idea. >> >> Sure, invocations of function-like macros should look like >> function calls (that's the whole point). Except that most macros >> should have all-caps names, unless they're meant to be direct >> replacements for equivalent functions. > > I prefer my function-like macros to have small-caps names - they are > function-like, and so I like them to look like functions. I prefer lower case for simple wrappers, if allowed by the project's style, but I strictly use upper case if the macro may evaluate any of its arguments more than once--as in all of the cases above--or if the macro modifies any of its arguments. I prefer static inline functions over function-like macros, and I'll convert them where I can, but if they modify their arguments, that usually means modifying every call, which can be an enormous task. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-10 10:27 -0700 |
| Message-ID | <kfnr3qoe41e.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61729 |
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:
>>> [...]
>>>> To summarize, I favor 'if( a == b )' over 'if (a==b)' because the
>>>> first form takes less effort both physically and mentally, as
>>>> detailed above. Make sense?
>>>
>>> Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same
>>> reason.
>>
>> That's fine but you don't say what factors influence that. Can
>> you say anything about what those are?
>
> Not a whole lot.
>
>> Might it be that you
>> find the first form easier just because that's what you are
>> used to?
>
> That's likely. I also have a vague preference for making things
> that aren't function calls not look like function calls:
>
> fn(a == b);
> if (a == b) {
> // ...
> }
It seems like two things are true: you are able to read either
form without too much difficulty, and your preferences derive
largely from what you are used to. Is that a fair summary?
I ask because I'm hoping to raise the discussion (not just with
you) above the level of "this is what I like". What are the
different factors that affect how easy it is to read something
(ie, some code)? To what extent are these factors inherent in a
person's visual system or cognitive system, and to what extent
are they learned behavior? Which decisions are made because they
affect readability directly, and which are made for other reasons
or because they affect readability only indirectly?
My goal here is not to challenge your views but to understand
them. Different people are different, and what is readable to
one person may be much less so to another, even for inherent
causes. My standard example is syntax highlighting, which I know
some people like, but it does nothing for me (or less than
nothing if that's possible). The reason is simple: I have poor
color vision - the hardware in my eyes simply doesn't perform the
way it does for most people. And I think there are analogous
factors on the cognitive side, eg, dyslexia. (I hasten to add
that this example is just speculation on my part, I know very
little about dyslexia.) Until we can understand the inherent
drivers of different expressional choices, the conversation will
probably be not very productive. The hope is that digging deeper
will yield insights that, at least potentially, benefit everyone.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-10 10:50 -0700 |
| Message-ID | <a50a4428-6b71-46ee-b29d-4018b4fbeecf@googlegroups.com> |
| In reply to | #61826 |
On Sunday, May 10, 2015 at 10:27:49 AM UTC-7, Tim Rentsch wrote: > > My goal here is not to challenge your views but to understand > them. Different people are different, and what is readable to > one person may be much less so to another, even for inherent > causes. My standard example is syntax highlighting, which I know > some people like, but it does nothing for me (or less than > nothing if that's possible). The reason is simple: I have poor > color vision - the hardware in my eyes simply doesn't perform the > way it does for most people. And I think there are analogous > factors on the cognitive side, eg, dyslexia. (I hasten to add > that this example is just speculation on my part, I know very > little about dyslexia.) Until we can understand the inherent > drivers of different expressional choices, the conversation will > probably be not very productive. The hope is that digging deeper > will yield insights that, at least potentially, benefit everyone. I don't much like syntax highlighting and, other than recently removed cataracts, my eyes are quite normal. I usually turn it off. I see it as garish and it clashes with the message the text is trying to convey. And, in the implementations I have seen, there is one large flaw in C (any C). The typedef names are not recognized as type names. I am unsure why anybody ever wanted syntax highlighting so I can't guess what purpose it serves - but to have some cases of something hightlighted and some not is quite disconcerting. So - why is highlighting ever useful? Why is it so popular?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-10 19:09 +0100 |
| Message-ID | <mio6rc$r04$1@dont-email.me> |
| In reply to | #61828 |
On 10/05/15 18:50, David Kleinecke wrote: <snip> > The typedef names are not recognized as type names. I am unsure why > anybody ever wanted syntax highlighting so I can't guess what purpose > it serves - but to have some cases of something hightlighted and > some not is quite disconcerting. True enough, but it's a minor problem. > So - why is highlighting ever useful? Why is it so popular? Just today my syntax-highlighting editor, gvim, told me (via syntax highlighting) that char might not be a great name for an object. :-) Sure, the compiler would have told me the same thing, but it was nice to be told right there and then at the edit stage. I find it helpful for #if 0'd code to be greyed out. In a similar vein, I appreciate the visual feedback that reminds me to add a */ after I've been busily typing the body of a /* or a " after I've been "adding a string. I can live without syntax highlighting, but I'd rather have it than not. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-12 04:54 -0700 |
| Message-ID | <kfn8ucuc8og.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61831 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 10/05/15 18:50, David Kleinecke wrote: > > <snip> > >> The typedef names are not recognized as type names. I am unsure >> why anybody ever wanted syntax highlighting so I can't guess what >> purpose it serves - but to have some cases of something >> hightlighted and some not is quite disconcerting. > > True enough, but it's a minor problem. It is minor, for some. For others, it isn't. >> So - why is highlighting ever useful? Why is it so popular? > > Just today my syntax-highlighting editor, gvim, told me (via > syntax highlighting) that char might not be a great name for an > object. :-) > > Sure, the compiler would have told me the same thing, but it was > nice to be told right there and then at the edit stage. > > I find it helpful for #if 0'd code to be greyed out. In a similar > vein, I appreciate the visual feedback that reminds me to add a */ > after I've been busily typing the body of a /* or a " after I've > been "adding a string. > > I can live without syntax highlighting, but I'd rather have it > than not. This exchange illustrates my point. In some cases different people have different reactions because of low-level differences in how their visual systems work. You find there are some benefits from using syntax highlighting. I don't get the same benefits, or perhaps they don't benefit me as much, but even if I did I still wouldn't use syntax highlighting because - for me - the visual distraction cost is so much higher. I am all in favor of you (and of course other people in the same boat) continuing using syntax highlighting. At the same time I don't want people automatically assuming that because it helps them it also helps me, for that is certainly not the case (and indeed IME quite the contrary).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-12 13:19 +0100 |
| Message-ID | <misr1k$ion$1@dont-email.me> |
| In reply to | #61895 |
On 12/05/15 12:54, Tim Rentsch wrote: <snip> > I am all in favor > of you (and of course other people in the same boat) continuing > using syntax highlighting. At the same time I don't want people > automatically assuming that because it helps them it also helps > me, for that is certainly not the case (and indeed IME quite the > contrary). I think the French use the expression "Vive la difference!" Diversity is a strength, not a weakness. Whether it's syntax highlighting, brace style, spacing and other layout issues, everybody has their own favourite way, and we should embracket, emparenthesise, or perhaps even embrace that diversity. It's a tiny matter, but one that we often blow out of all proportion; if we're going to be reading other people's code, we should expect to be faced with code that isn't in our preferred style or colour, and do so without grumbling. If we are truly at a loss, there's always indent(1). -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-12 05:26 -0700 |
| Message-ID | <5150d512-a388-4f6c-95da-e1dec849360b@googlegroups.com> |
| In reply to | #61897 |
On Tuesday, May 12, 2015 at 1:19:10 PM UTC+1, Richard Heathfield wrote: > On 12/05/15 12:54, Tim Rentsch wrote: > > Diversity is a strength, not a weakness. Whether it's syntax > highlighting, brace style, spacing and other layout issues, everybody > has their own favourite way, and we should embracket, emparenthesise, or > perhaps even embrace that diversity. It's a tiny matter, but one that we > often blow out of all proportion; if we're going to be reading other > people's code, we should expect to be faced with code that isn't in our > preferred style or colour, and do so without grumbling. If we are truly > at a loss, there's always indent(1). > Not really. Pre-18th century texts have variable spelling. Printers would spell a word differently to right-justify their text. It's not a big deal, you can still read it. But it is a bit harder than for fixed systems (it's not just a matter of familiarity, the same applies in foreign languages).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-12 08:31 -0700 |
| Message-ID | <87bnhpg6d1.fsf@kst-u.example.com> |
| In reply to | #61897 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/05/15 12:54, Tim Rentsch wrote:
>> I am all in favor
>> of you (and of course other people in the same boat) continuing
>> using syntax highlighting. At the same time I don't want people
>> automatically assuming that because it helps them it also helps
>> me, for that is certainly not the case (and indeed IME quite the
>> contrary).
>
> I think the French use the expression "Vive la difference!"
>
> Diversity is a strength, not a weakness. Whether it's syntax
> highlighting, brace style, spacing and other layout issues, everybody
> has their own favourite way, and we should embracket, emparenthesise,
> or perhaps even embrace that diversity. It's a tiny matter, but one
> that we often blow out of all proportion; if we're going to be reading
> other people's code, we should expect to be faced with code that isn't
> in our preferred style or colour, and do so without grumbling. If we
> are truly at a loss, there's always indent(1).
On the other hand, the 8th of Henry Spencer's "Ten Commandments for C
Programmers" is:
Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest it
not, for thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.
Diversity *within a project* can be a real problem. I'd much rather use
a consistent brace style I don't like than work with code that mixes
different styles.
--
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:40 +0100 |
| Message-ID | <mit6r4$303$2@dont-email.me> |
| In reply to | #61905 |
On 12/05/15 16:31, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 12/05/15 12:54, Tim Rentsch wrote: >>> I am all in favor >>> of you (and of course other people in the same boat) continuing >>> using syntax highlighting. At the same time I don't want people >>> automatically assuming that because it helps them it also helps >>> me, for that is certainly not the case (and indeed IME quite the >>> contrary). >> >> I think the French use the expression "Vive la difference!" >> >> Diversity is a strength, not a weakness. Whether it's syntax >> highlighting, brace style, spacing and other layout issues, everybody >> has their own favourite way, and we should embracket, emparenthesise, >> or perhaps even embrace that diversity. It's a tiny matter, but one >> that we often blow out of all proportion; if we're going to be reading >> other people's code, we should expect to be faced with code that isn't >> in our preferred style or colour, and do so without grumbling. If we >> are truly at a loss, there's always indent(1). > > On the other hand, the 8th of Henry Spencer's "Ten Commandments for C > Programmers" is: > > Thou shalt make thy program's purpose and structure clear to thy > fellow man by using the One True Brace Style, even if thou likest it > not, for thy creativity is better used in solving problems than in > creating beautiful new impediments to understanding. This clause has been made the subject of a DR. A maintenance release of the Commandments will doubtless be forthcoming in due course. > Diversity *within a project* can be a real problem. I'd much rather use > a consistent brace style I don't like than work with code that mixes > different styles. Sure, but that's what indent(1) is for. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-20 10:28 -0700 |
| Message-ID | <kfna8wzb1kf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61897 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 12/05/15 12:54, Tim Rentsch wrote: > > <snip> > >> I am all in favor >> of you (and of course other people in the same boat) continuing >> using syntax highlighting. At the same time I don't want people >> automatically assuming that because it helps them it also helps >> me, for that is certainly not the case (and indeed IME quite the >> contrary). > > I think the French use the expression "Vive la difference!" They do, but that has rather a different connotation. > Diversity is a strength, not a weakness. Whether it's syntax > highlighting, brace style, spacing and other layout issues, > everybody has their own favourite way, and we should embracket, > emparenthesise, or perhaps even embrace that diversity. There is a distinction here that is important to note. If someone use a syntax-highlighting editor, that has no direct effect on other people. But how code is written does directly affect everyone who reads it. So the relevant considerations are different in the two cases. > It's a > tiny matter, but one that we often blow out of all proportion; if > we're going to be reading other people's code, we should expect to > be faced with code that isn't in our preferred style or colour, > and do so without grumbling. This statement is contrary to my central point, to wit, that the nervous systems of different people have different response functions, and that should be acknowledged and accepted, not dismissed. It is not "preference" that makes me unable to distinguish colors that most other people can. Analogous results (in either direction) hold true in the cognitive space as well as the perceptual space. Framing the discussion in terms of preference and grumbling perpetuates the problem, and that is just what I am hoping to alleviate. > If we are truly at a loss, there's always indent(1). I agree in a general way with the second part, but it's too simplistic. Using indent, or something like it, is a good starting point for the discussion, but it is nowhere near the last word on the subject.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-10 11:39 -0700 |
| Message-ID | <871tiogtv0.fsf@kst-u.example.com> |
| In reply to | #61826 |
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:
>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> [...]
>>>>> To summarize, I favor 'if( a == b )' over 'if (a==b)' because the
>>>>> first form takes less effort both physically and mentally, as
>>>>> detailed above. Make sense?
>>>>
>>>> Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same
>>>> reason.
>>>
>>> That's fine but you don't say what factors influence that. Can
>>> you say anything about what those are?
>>
>> Not a whole lot.
>>
>>> Might it be that you
>>> find the first form easier just because that's what you are
>>> used to?
>>
>> That's likely. I also have a vague preference for making things
>> that aren't function calls not look like function calls:
>>
>> fn(a == b);
>> if (a == b) {
>> // ...
>> }
>
> It seems like two things are true: you are able to read either
> form without too much difficulty, and your preferences derive
> largely from what you are used to. Is that a fair summary?
Yes. I find `if(a==b)` or `if(a == b)` slightly jarring, but not
difficult to read.
There are certainly cases where added whitespace makes things easier
for me to read, because it takes more effort to realize that two
adjacent tokens are distinct and adding a space makes that easier.
For whatever reason, adding a space after ( or before ) isn't
particularly helpful to me; `(a` clearly looks like two tokens even
without a space.
[...]
> My standard example is syntax highlighting, which I know
> some people like, but it does nothing for me (or less than
> nothing if that's possible). The reason is simple: I have poor
> color vision - the hardware in my eyes simply doesn't perform the
> way it does for most people.
[...]
I find syntax highlighting with well-chosen colors tolerable.
Some configurations are more difficult. In some cases, I think the
colors are chosen to look good with light text on a dark background.
I configure my terminal emulator to use black text on a white
background. Yellow text on a black background is reasonable;
yellow text on a white background is nearly invisible. No doubt
there are ways to force various tools to use reasonable colors,
but since I don't generally use color I haven't taken the time to
figure out the details.
--
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-12 05:33 -0700 |
| Message-ID | <kfn4mnic6vx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61835 |
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:
>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>> [...]
>>>>>> To summarize, I favor 'if( a == b )' over 'if (a==b)' because
>>>>>> the first form takes less effort both physically and mentally,
>>>>>> as detailed above. Make sense?
>>>>>
>>>>> Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same
>>>>> reason.
>>>>
>>>> That's fine but you don't say what factors influence that. Can
>>>> you say anything about what those are?
>>>
>>> Not a whole lot.
>>>
>>>> Might it be that you
>>>> find the first form easier just because that's what you are
>>>> used to?
>>>
>>> That's likely. I also have a vague preference for making things
>>> that aren't function calls not look like function calls:
>>>
>>> fn(a == b);
>>> if (a == b) {
>>> // ...
>>> }
>>
>> It seems like two things are true: you are able to read either
>> form without too much difficulty, and your preferences derive
>> largely from what you are used to. Is that a fair summary?
>
> Yes. I find `if(a==b)` or `if(a == b)` slightly jarring, but not
> difficult to read.
>
> There are certainly cases where added whitespace makes things
> easier for me to read, because it takes more effort to realize
> that two adjacent tokens are distinct and adding a space makes
> that easier. For whatever reason, adding a space after ( or
> before ) isn't particularly helpful to me; `(a` clearly looks
> like two tokens even without a space.
I do find it more helpful in some cases than others. But since I
find it almost always helps at least a little, and (for me) almost
never hurts, it seems better overall to follow the rule always.
> [...]
>
>> My standard example is syntax highlighting, which I know
>> some people like, but it does nothing for me (or less than
>> nothing if that's possible). The reason is simple: I have poor
>> color vision - the hardware in my eyes simply doesn't perform the
>> way it does for most people.
>
> [...]
>
> I find syntax highlighting with well-chosen colors tolerable.
> Some configurations are more difficult. In some cases, I think
> the colors are chosen to look good with light text on a dark
> background. I configure my terminal emulator to use black text
> on a white background. Yellow text on a black background is
> reasonable; yellow text on a white background is nearly
> invisible. No doubt there are ways to force various tools to
> use reasonable colors, but since I don't generally use color I
> haven't taken the time to figure out the details.
Yes, it's definitely a challenge to get color schemes right
because of individual variations in eye response (both color and
intensity). In my case I use white text on a black background,
as the other way is somewhat painful on my eyes. Interestingly
there is a correlation with eye color - people with a dark eye
color are more often in the black-on-white category, whereas
a lighter eye color is more often in the white-on-black category
(in both cases relative to an average).
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-07 17:59 -0500 |
| Message-ID | <migqm2$rla$1@dont-email.me> |
| In reply to | #61723 |
On 07-May-15 15:36, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same
>> reason.
>
> That's fine but you don't say what factors influence that. Can
> you say anything about what those are? Might it be that you
> find the first form easier just because that's what you are
> used to?
Since Keith didn't have anything to say, but my preference is similar
('if (a==b)'), I'll take a stab at it.
First, 'if( ... )' looks too much like a function call; it's not, so I
prefer 'if ( ... )'.
Second, '( ... )' wastes space, and I prefer parentheses visually bound
to what they're containing: '(...)'.
Third, 'a == b' likewise wastes space; I'd write that as 'a==b', unless
'a' and/or 'b' were actually complicated sub-expressions where extra
space may help logically group things, like invisible parentheses.
Adding "unnecessary" spaces or parentheses can make some expressions
more clear, but adding too many can instead make them less clear--and I
tend to err on the side of too few simply so more code fits on the
screen. Ditto for why I prefer 1TBS brace/indent style.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-11 09:20 -0700 |
| Message-ID | <kfnmw1bdr26.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61733 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 07-May-15 15:36, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same
>>> reason.
>>
>> That's fine but you don't say what factors influence that. Can
>> you say anything about what those are? Might it be that you
>> find the first form easier just because that's what you are
>> used to?
>
> Since Keith didn't have anything to say, but my preference is
> similar ('if (a==b)'), I'll take a stab at it.
Excellent! Thank you for taking the time.
> First, 'if( ... )' looks too much like a function call; it's not,
> so I prefer 'if ( ... )'.
>
> Second, '( ... )' wastes space, and I prefer parentheses visually
> bound to what they're containing: '(...)'.
>
> Third, 'a == b' likewise wastes space; I'd write that as 'a==b',
> unless 'a' and/or 'b' were actually complicated sub-expressions
> where extra space may help logically group things, like invisible
> parentheses.
>
> Adding "unnecessary" spaces or parentheses can make some
> expressions more clear, but adding too many can instead make them
> less clear--and I tend to err on the side of too few simply so
> more code fits on the screen. Ditto for why I prefer 1TBS
> brace/indent style.
There are several different aspects here, let me ask about them
one at a time. First about conserving spaces.
Consider the following two expression statements, which differ
only in spacing (and assume both fit easily on the line where
they would appear, including indentation etc):
(1) printf("foo[ %2d ] is %9.2f\n",i,foo[i]);
(2) printf( "foo[ %2d ] is %9.2f\n", i, foo[i] );
Would you say
(a) (1) is markedly easier to read than (2)
(b) (1) is slightly easier to read than (2)
(c) (1) and (2) are about the same in ease of reading
(d) (2) is slightly easier to read than (1)
(e) (2) is markedly easier to read than (1)
If the answer is other than (c), what cognitive or perceptual
factors play a role in that? To what extent are these influenced
mostly by what you are used to, as opposed to being inherent in
the neurological "hardware" or "firmware" that does the reading?
I think most developers would agree that there is a tension
between expressing code compactly and limiting visual density.
Do you agree with this principle? Where would you put yourself
on the compactness/openness spectrum (and I admit the labels
I'm using are pretty vague):
(a) Compactness is much more important than visual openness;
(b) Compactness deserves a weight between 1x and 2x that of
visual openness;
(c) Compactness and visual openness are equally important;
(d) Visual openness deserves a weight between 1x and 2x that
of compactness; or
(e) Visual openness is much more important than compactness.
Note that compactness and openness are not necessarily mutually
exclusive, because in most cases there is free space at the end
of lines after declaration or statement breaks.
Considering these two forms of if(),
(1) if (a == b) {
(2) if( a == b ){
the same amount of horizontal space is used. Does this mean that
your wanting to conserve spaces does not influence the question
of which of the two is preferable? If not then why not?
In broad terms I'm not sure how much of what you say is about how
you think code should be written (for whatever considerations),
and how much is about how easy to read (or not) the different
results are. Asking just about conserving space, which of
the following most closely matches your view?
(a) Conserving spaces has a strong and direct effect on ease
of reading;
(b) Conserving spaces has a moderate direct effect on ease
of reading, but also is important for other reasons;
(c) Conserving spaces sometimes has a direct effect on ease
of reading but also has indirect effects that contribute
to that (and are significant);
(d) Conserving spaces primarily has an indirect benefit on
ease of reading; or
(e) Conserving spaces is important only for larger scale
considerations (notably, length of function bodies)
that affect "readability in the large", but does not
affect ease of reading locally.
Of course please feel free to make up your own answer if none of
the above adequately represents your view.
Digressing slightly, I can't resist asking a question about
vertical spacing. I am also a fan of 1TBS (shameless editorial
comment - as any sensible person would be). However I think the
considerations for horizontal spacing and for vertical spacing
are not exactly the same, because of the asymmetry between the
two dimensions in code writing. (Compare for example to prose
writing.) In particular I am often interested in how many lines
are used (eg, by a function definition), but only rarely about
how wide a line is, because most lines end naturally before their
hard limit (nominally 79 columns). Do you often run into cases
where line width exceeds (or would exceed, if not addressed) the
nominal limit? Or to ask that another way, do you often see
cases where a "logical line" needs to be continued across more
than on physical line? I'm just curious. Also, related to that,
how much indentation per nesting level are you accustomed to (a
multi-valued answer definitely possible here)? And now finally
the question about vertical space: as an average, what would you
say is a reasonable amount of intra-function-definition blank
lines, considering just the body of each function (and not the
open/close brace lines), rounded to the nearst 5%:
(a) 0%
(b) 5%
(c) 10%
(d) 15%
(e) 20%
(f) 25+%
I realize you may not have a ready answer for this, I'm just
asking for your best guess for an average.
I do have some other stuff to ask about on the other items you
mentioned but let me stop here for now and post this, and
continue in another message.
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web