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 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-04-30 10:00 -0700 |
| Message-ID | <90e347f4-52c8-4954-9817-fcbca4819b3a@googlegroups.com> |
| In reply to | #61332 |
On Thursday, April 30, 2015 at 7:35:35 AM UTC-7, David Brown wrote:
> On 30/04/15 14:48, Bartc wrote:
> > On 30/04/2015 12:47, David Brown wrote:
> >
> >> The sort of thing I am thinking of is when there are mixes of style due
> >> to multiple authors of a file:
> >>
> >> if (a == 1)
> >> {
> >> foo(10);
> >> }
> >>
> >> if (a==2) foo(20);
> >>
> >> if( a==3 )
> >> foo(30);
> >>
> >> if (a == 4) {
> >> foo(40);
> >> }
> >>
> >> if (a == 5) {
> >> foo(50);
> >> }
> >>
> >>
> >> These sorts of mixups make code harder to read than necessary.
> >
> > This demonstrates one of the many things I don't like about braces - so
> > many different possibilities. There is also:
> >
> > if (a == 6)
> > { foo(60);
> > }
> >
> > if (a == 7) {foo(70);}
> >
> > if (a == 8) {
> > foo(80);}
> >
> > if (a == 9)
> > { foo(90);}
> >
> > etc. I generate C code now and that always uses your a==4 style, but
> > there it probably doesn't matter as it's not meant to be read (unless
> > there is a problem).
>
> "a == 4" style is the one I use too.
>
> >
> > BTW what's the difference between a==4 and a==5; tabbing style? That can
> > be applied to all the others too and is a separate matter from that of
> > brace placement.
> >
>
> Yes, "a == 4" had a tab character, while "a == 5" had two spaces. These
> things don't always survive news reader quoting.
>
> The examples were more general style differences than just braces, and
> were only a small fraction of the variations that could be used - I
> didn't plan to enumerate them all! The point is that if different
> styles are used in the same source file, it becomes harder to read - and
> so when making small changes, it might make more sense to value
> consistency with existing code above the benefits of your own favourite
> style.
Perhaps we need a new profession - code editor.
A code editor has a rough job - change the formal code statement without
changing the black box actions of the code.
Only a multiple programmer project should need a code editor. But even
a solitary programmer might get good use of of the editors tools. Like
lint.
The (production) code resulting from a multiple programmer project should
be the single product of the entire team. Not a patched-together
collection of sub-products by different people. The code editor is in
charge of integration. Everybody's eyes should see every thing.
And, in the spirit of literate programming, the editor is in charge of
making the code readable.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-01 06:25 -0700 |
| Message-ID | <kfnoam4o2fg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61316 |
David Brown <david.brown@hesbynett.no> writes:
> On 30/04/15 13:10, Tim Rentsch wrote:
>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>
>>> On 2015-04-16, David Brown <david.brown@hesbynett.no> wrote:
>>>> On 15/04/15 20:46, Tim Rentsch wrote:
>>>>> What makes code readable?
>>>>
>>>> The biggest key on the keyboard is the space key. The second
>>>> biggest (on many keyboards) is the return key. Make good use
>>>> of them!
>>>
>>> This is number one for me.
>>>
>>> I'm not so young any more and sometimes find myself working with
>>> younger programmers who don't appreciate space - I know there
>>> eyes hold up better then mine because I see the size of the font
>>> they use in their editors - I need room around everyting and
>>> have developed a style I find very readable. [snip example]
>>
>> Completely with you on this one. In most cases I run code
>> through a formatter before I really look at it.
>>
>>>> Consistency of style is more important than details of the style
>>>> itself.
>>>
>>> I have heard this expressed before but don't 100% agree though it
>>> may be I'm in agreement with the spirit of it. [snip example]
>>
>> I agree partly, but only partly. One of the ways I don't agree
>> is the implicit idea that there should only be one way of doing
>> any given thing. For some things that's true, for others not
>> as much. So for me when I hear this kind of general statement
>> I usually think "here's an area that needs a deeper conversation."
>
> The sort of thing I am thinking of is when there are mixes of
> style due to multiple authors of a file:
>
> if (a == 1)
> {
> foo(10);
> }
>
> if (a==2) foo(20);
>
> if( a==3 )
> foo(30);
>
> if (a == 4) {
> foo(40);
> }
>
> if (a == 5) {
> foo(50);
> }
>
>
> These sorts of mixups make code harder to read than necessary.
> Sometimes if you are making a small change in the code, it is
> better to use the existing style than to use your own style (even
> though you /know/ your style is better).
Okay, good example.
The point I was trying to make above is that these choices are
not necessarily mutually exclusive. In particular, the a==2
choice might be combined with one of a=={1,4,5}, even by the same
author. Taking a==4 as representative, I might very well use
both the a==2 and a==4 styles, depending on what it is I'm trying
to express. The admonition to use a consistent style is often
(IME) taken to mean there must be only a single choice, even
among cases that are not necessarily mutually exclusive. So it
isn't that I disagree with the advice, but I think what is
desired needs to be communicated more carefully, because the
situation is not as simple as it might (and unfortunately often
does) appear.
> The exception, of course, is for the "a==3" case above - don't
> copy that style!
I agree with this recommendation, but not for reasons of
readability; I don't find the a==3 case hard to read, especially
if it is followed by a blank line. The reasons to avoid this
construction have more to do with development process than they do
readability - the danger of inadvertently altering the semantics
in unintended ways during editing, even if small, is still too
high.
>>>> Don't make code unnecessarily long-winded, but it is usually
>>>> worse to try and make it too short or compact. Don't be afraid
>>>> to split things up, or add extra functions or temporary variables
>>>> in order to make the code clearer. Try to avoid repeating the
>>>> same code - but don't be obsessive about it - it is better with
>>>> two almost-verbatim copies of the same clear code, than one
>>>> combined but illegible sequence.
>>>
>>> There are variables that should be very short since giving them a
>>> longer name adds nothing but clutter; consistancy in naming can
>>> give them adequate context. [snip example]
>>
>> I agree with this. Actually I think there is another dimension
>> here, namely, besides the question of which names should be
>> long and which names should be short, there is also the question
>> of namings are "good" (or "allowed") in each category, because
>> what sorts of names work when a variable name is long is
>> different than what sorts of names work when a variable name
>> is short. (Also I believe that there are more than just two
>> categories (ie, "long" and "short"), but I will leave that
>> for another time.)
>
> Yes. Roughly speaking, the smaller the scope of an identifier,
> the shorter its name can be. But I agree that it's not something
> that can be split into just two categories.
I would identify at least six different cases even based just on how
widely an identifier is "visible" -
(a) Top-level global (ie, an 'extern');
(b) Top-level but file-local (ie, 'static');
(c) Function parameter;
(d) Function local in a short function;
(e) Function local in a long function; and
(f) Block-level temporary (ie, or loop variable, etc).
Naming considerations are different in each of these cases.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-02 15:53 +0200 |
| Message-ID | <mi2kr2$s0o$1@dont-email.me> |
| In reply to | #61352 |
On 01/05/15 15:25, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 30/04/15 13:10, Tim Rentsch wrote:
>>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>>
>>>> On 2015-04-16, David Brown <david.brown@hesbynett.no> wrote:
>>>>> On 15/04/15 20:46, Tim Rentsch wrote:
>>>>>> What makes code readable?
>>>>>
>>>>> The biggest key on the keyboard is the space key. The second
>>>>> biggest (on many keyboards) is the return key. Make good use
>>>>> of them!
>>>>
>>>> This is number one for me.
>>>>
>>>> I'm not so young any more and sometimes find myself working with
>>>> younger programmers who don't appreciate space - I know there
>>>> eyes hold up better then mine because I see the size of the font
>>>> they use in their editors - I need room around everyting and
>>>> have developed a style I find very readable. [snip example]
>>>
>>> Completely with you on this one. In most cases I run code
>>> through a formatter before I really look at it.
>>>
>>>>> Consistency of style is more important than details of the style
>>>>> itself.
>>>>
>>>> I have heard this expressed before but don't 100% agree though it
>>>> may be I'm in agreement with the spirit of it. [snip example]
>>>
>>> I agree partly, but only partly. One of the ways I don't agree
>>> is the implicit idea that there should only be one way of doing
>>> any given thing. For some things that's true, for others not
>>> as much. So for me when I hear this kind of general statement
>>> I usually think "here's an area that needs a deeper conversation."
>>
>> The sort of thing I am thinking of is when there are mixes of
>> style due to multiple authors of a file:
>>
>> if (a == 1)
>> {
>> foo(10);
>> }
>>
>> if (a==2) foo(20);
>>
>> if( a==3 )
>> foo(30);
>>
>> if (a == 4) {
>> foo(40);
>> }
>>
>> if (a == 5) {
>> foo(50);
>> }
>>
>>
>> These sorts of mixups make code harder to read than necessary.
>> Sometimes if you are making a small change in the code, it is
>> better to use the existing style than to use your own style (even
>> though you /know/ your style is better).
>
> Okay, good example.
>
> The point I was trying to make above is that these choices are
> not necessarily mutually exclusive. In particular, the a==2
> choice might be combined with one of a=={1,4,5}, even by the same
> author. Taking a==4 as representative, I might very well use
> both the a==2 and a==4 styles, depending on what it is I'm trying
> to express. The admonition to use a consistent style is often
> (IME) taken to mean there must be only a single choice, even
> among cases that are not necessarily mutually exclusive. So it
> isn't that I disagree with the advice, but I think what is
> desired needs to be communicated more carefully, because the
> situation is not as simple as it might (and unfortunately often
> does) appear.
>
Agreed. Being "consistent" can easily allow different variations in
different contexts (I too use "a == 2" style in some circumstances, even
though "a == 4" is more common in my code). My point is to limit the
varieties in a file in order to make it easier to read - it is not a
good thing for some parts of the code to stand out against the others
simply because they use spacing in a different way.
>> The exception, of course, is for the "a==3" case above - don't
>> copy that style!
>
> I agree with this recommendation, but not for reasons of
> readability; I don't find the a==3 case hard to read, especially
> if it is followed by a blank line. The reasons to avoid this
> construction have more to do with development process than they do
> readability - the danger of inadvertently altering the semantics
> in unintended ways during editing, even if small, is still too
> high.
That's the reason for avoiding such a style without brackets. But I
also dislike the lack of space after "if", and find the spacing around
the comparison to be ugly - I personally find that it affects
readability. (I probably should have been more careful to handle one
difference at a time, rather than having multiple style differences in
each example - but I hadn't planned on going into such detail of exactly
what is wrong with each style.)
>
>>>>> Don't make code unnecessarily long-winded, but it is usually
>>>>> worse to try and make it too short or compact. Don't be afraid
>>>>> to split things up, or add extra functions or temporary variables
>>>>> in order to make the code clearer. Try to avoid repeating the
>>>>> same code - but don't be obsessive about it - it is better with
>>>>> two almost-verbatim copies of the same clear code, than one
>>>>> combined but illegible sequence.
>>>>
>>>> There are variables that should be very short since giving them a
>>>> longer name adds nothing but clutter; consistancy in naming can
>>>> give them adequate context. [snip example]
>>>
>>> I agree with this. Actually I think there is another dimension
>>> here, namely, besides the question of which names should be
>>> long and which names should be short, there is also the question
>>> of namings are "good" (or "allowed") in each category, because
>>> what sorts of names work when a variable name is long is
>>> different than what sorts of names work when a variable name
>>> is short. (Also I believe that there are more than just two
>>> categories (ie, "long" and "short"), but I will leave that
>>> for another time.)
>>
>> Yes. Roughly speaking, the smaller the scope of an identifier,
>> the shorter its name can be. But I agree that it's not something
>> that can be split into just two categories.
>
> I would identify at least six different cases even based just on how
> widely an identifier is "visible" -
>
> (a) Top-level global (ie, an 'extern');
>
> (b) Top-level but file-local (ie, 'static');
>
> (c) Function parameter;
>
> (d) Function local in a short function;
>
> (e) Function local in a long function; and
>
> (f) Block-level temporary (ie, or loop variable, etc).
>
> Naming considerations are different in each of these cases.
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-03 10:42 -0700 |
| Message-ID | <kfnd22hmuan.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61386 |
David Brown <david.brown@hesbynett.no> writes:
> On 01/05/15 15:25, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 30/04/15 13:10, Tim Rentsch wrote:
>>>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>>>
>>>>> On 2015-04-16, David Brown <david.brown@hesbynett.no> wrote:
>>>>>> On 15/04/15 20:46, Tim Rentsch wrote:
>>>>>>> What makes code readable?
>>>>>>
>>>>>> The biggest key on the keyboard is the space key. The second
>>>>>> biggest (on many keyboards) is the return key. Make good use
>>>>>> of them!
>>>>>
>>>>> This is number one for me.
>>>>>
>>>>> I'm not so young any more and sometimes find myself working with
>>>>> younger programmers who don't appreciate space - I know there
>>>>> eyes hold up better then mine because I see the size of the font
>>>>> they use in their editors - I need room around everyting and
>>>>> have developed a style I find very readable. [snip example]
>>>>
>>>> Completely with you on this one. In most cases I run code
>>>> through a formatter before I really look at it.
>>>>
>>>>>> Consistency of style is more important than details of the style
>>>>>> itself.
>>>>>
>>>>> I have heard this expressed before but don't 100% agree though it
>>>>> may be I'm in agreement with the spirit of it. [snip example]
>>>>
>>>> I agree partly, but only partly. One of the ways I don't agree
>>>> is the implicit idea that there should only be one way of doing
>>>> any given thing. For some things that's true, for others not
>>>> as much. So for me when I hear this kind of general statement
>>>> I usually think "here's an area that needs a deeper conversation."
>>>
>>> The sort of thing I am thinking of is when there are mixes of
>>> style due to multiple authors of a file:
>>>
>>> if (a == 1)
>>> {
>>> foo(10);
>>> }
>>>
>>> if (a==2) foo(20);
>>>
>>> if( a==3 )
>>> foo(30);
>>>
>>> if (a == 4) {
>>> foo(40);
>>> }
>>>
>>> if (a == 5) {
>>> foo(50);
>>> }
>>>
>>>
>>> These sorts of mixups make code harder to read than necessary.
>>> Sometimes if you are making a small change in the code, it is
>>> better to use the existing style than to use your own style (even
>>> though you /know/ your style is better).
>>
>> Okay, good example.
>>
>> The point I was trying to make above is that these choices are
>> not necessarily mutually exclusive. In particular, the a==2
>> choice might be combined with one of a=={1,4,5}, even by the same
>> author. Taking a==4 as representative, I might very well use
>> both the a==2 and a==4 styles, depending on what it is I'm trying
>> to express. The admonition to use a consistent style is often
>> (IME) taken to mean there must be only a single choice, even
>> among cases that are not necessarily mutually exclusive. So it
>> isn't that I disagree with the advice, but I think what is
>> desired needs to be communicated more carefully, because the
>> situation is not as simple as it might (and unfortunately often
>> does) appear.
>
> Agreed. Being "consistent" can easily allow different variations
> in different contexts (I too use "a == 2" style in some
> circumstances, even though "a == 4" is more common in my code).
> My point is to limit the varieties in a file in order to make it
> easier to read - it is not a good thing for some parts of the code
> to stand out against the others simply because they use spacing in
> a different way.
I agree with you up to a point, but only up to a point. It's
easy to fall into the trap of over-prescribing. For example,
should there be two or three (or four or five?) blank lines
between function definitions? If I'm editing a file that happens
to use two blank lines between function definitions, and I happen
to put in three or four for a function I write, that shouldn't be
any big deal. There are plenty of other cases (and I'm sure you
must have seen some) where style guideline documents are overly
restrictive, just to pay homage to the god of "consistency". So
I can agree with your statement as long as an appropriate number
of grains of salt are added. (Notice I was careful not to
over-prescribe how many. :)
>>> The exception, of course, is for the "a==3" case above - don't
>>> copy that style!
>>
>> I agree with this recommendation, but not for reasons of
>> readability; I don't find the a==3 case hard to read, especially
>> if it is followed by a blank line. The reasons to avoid this
>> construction have more to do with development process than they do
>> readability - the danger of inadvertently altering the semantics
>> in unintended ways during editing, even if small, is still too
>> high.
>
> That's the reason for avoiding such a style without brackets.
Right. My comment above is based on just that one aspect.
> But
> I also dislike the lack of space after "if", and find the spacing
> around the comparison to be ugly - I personally find that it
> affects readability.
Suppose you were talking to someone who has a different reaction.
(Incidentally I am one of those people, but this doesn't affect
my question.) Can you explain your reaction without the
explanation being circular? Here I am taking "ugly" as being
more or less a synonym for "hard to read". What about it
makes it hard to read? Is it just that this form is what you
are used to, and the unfamiliarity is jarring? Or something
else? If it is something else, then what?
By the way I have a related story to tell about this, but I
will save that for after your response.
> (I probably should have been more careful to
> handle one difference at a time, rather than having multiple style
> differences in each example - but I hadn't planned on going into
> such detail of exactly what is wrong with each style.)
No worries, it all came out in the wash.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-04 09:41 +0200 |
| Message-ID | <mi77pp$neu$1@dont-email.me> |
| In reply to | #61442 |
On 03/05/15 19:42, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > <snipping for brevity> > I agree with you up to a point, but only up to a point. It's > easy to fall into the trap of over-prescribing. This is important in any set of rules or guidelines about style or readability - getting a balance between flexibility and consistency. I don't believe it is possible to make solid rules here - it will depend too much on the task in hand, the people involved, and the surrounding circumstances. (As an example, making a file-wide change to the style or spacing can appear as massive changes to a file even though it doesn't affect the logic or generated code. This will easily cause confusion to people trying to find the important changes in a file's history.) > >>>> The exception, of course, is for the "a==3" case above - don't >>>> copy that style! >>> >>> I agree with this recommendation, but not for reasons of >>> readability; I don't find the a==3 case hard to read, especially >>> if it is followed by a blank line. The reasons to avoid this >>> construction have more to do with development process than they do >>> readability - the danger of inadvertently altering the semantics >>> in unintended ways during editing, even if small, is still too >>> high. >> >> That's the reason for avoiding such a style without brackets. > > Right. My comment above is based on just that one aspect. I realise that - even though it was the spacing that I was particularly interested in here (which is why I regret mixing bracket changes in the same example). > >> But >> I also dislike the lack of space after "if", and find the spacing >> around the comparison to be ugly - I personally find that it >> affects readability. > > Suppose you were talking to someone who has a different reaction. > (Incidentally I am one of those people, but this doesn't affect > my question.) Can you explain your reaction without the > explanation being circular? Here I am taking "ugly" as being > more or less a synonym for "hard to read". What about it > makes it hard to read? Is it just that this form is what you > are used to, and the unfamiliarity is jarring? Or something > else? If it is something else, then what? > There are some aspects of spacing that I think are objectively important - being consistent, having enough space to separate parts of the text, and not having so much space that it's hard to see what parts join onto each other. Thus "(a == 2)" is better than "(a== 2)". Beyond that, it is much more subjective. /I/ think "(a == 2)" is easier to read than "(a==2)", but I accept that some people might have different opinions. > By the way I have a related story to tell about this, but I > will save that for after your response. > >> (I probably should have been more careful to >> handle one difference at a time, rather than having multiple style >> differences in each example - but I hadn't planned on going into >> such detail of exactly what is wrong with each style.) > > No worries, it all came out in the wash. >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-05 07:01 -0700 |
| Message-ID | <kfnvbg7i0np.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61484 |
David Brown <david.brown@hesbynett.no> writes: > On 03/05/15 19:42, Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: > > <snipping for brevity> Ditto. >>> But >>> I also dislike the lack of space after "if", and find the spacing >>> around the comparison to be ugly - I personally find that it >>> affects readability. >> >> Suppose you were talking to someone who has a different reaction. >> (Incidentally I am one of those people, but this doesn't affect >> my question.) Can you explain your reaction without the >> explanation being circular? Here I am taking "ugly" as being >> more or less a synonym for "hard to read". What about it >> makes it hard to read? Is it just that this form is what you >> are used to, and the unfamiliarity is jarring? Or something >> else? If it is something else, then what? > > There are some aspects of spacing that I think are objectively > important - being consistent, having enough space to separate > parts of the text, and not having so much space that it's hard to > see what parts join onto each other. Thus "(a == 2)" is better > than "(a== 2)". What I think you mean is that these things have higher weighting factors and there is a higher degree of consensus about them. Is that a fair re-wording? > Beyond that, it is much more subjective. /I/ think "(a == 2)" is > easier to read than "(a==2)", but I accept that some people might > have different opinions. I get that this is what you think. What I'm trying to ask about is why you think it, in particular for what you said about a form like 'if( a == 2 )'. If all you can say is that you don't like it that isn't very helpful.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-06 09:34 +0200 |
| Message-ID | <micg4b$sru$1@dont-email.me> |
| In reply to | #61565 |
On 05/05/15 16:01, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 03/05/15 19:42, Tim Rentsch wrote: >>> David Brown <david.brown@hesbynett.no> writes: >> >> <snipping for brevity> > > Ditto. > >>>> But >>>> I also dislike the lack of space after "if", and find the spacing >>>> around the comparison to be ugly - I personally find that it >>>> affects readability. >>> >>> Suppose you were talking to someone who has a different reaction. >>> (Incidentally I am one of those people, but this doesn't affect >>> my question.) Can you explain your reaction without the >>> explanation being circular? Here I am taking "ugly" as being >>> more or less a synonym for "hard to read". What about it >>> makes it hard to read? Is it just that this form is what you >>> are used to, and the unfamiliarity is jarring? Or something >>> else? If it is something else, then what? >> >> There are some aspects of spacing that I think are objectively >> important - being consistent, having enough space to separate >> parts of the text, and not having so much space that it's hard to >> see what parts join onto each other. Thus "(a == 2)" is better >> than "(a== 2)". > > What I think you mean is that these things have higher weighting > factors and there is a higher degree of consensus about them. > Is that a fair re-wording? Yes, I think that's fair (noting of course that this is just my beliefs about such consensus - I have no statistics, surveys, etc., to back them up). > >> Beyond that, it is much more subjective. /I/ think "(a == 2)" is >> easier to read than "(a==2)", but I accept that some people might >> have different opinions. > > I get that this is what you think. What I'm trying to ask > about is why you think it, in particular for what you said > about a form like 'if( a == 2 )'. If all you can say is > that you don't like it that isn't very helpful. > You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ? "If" is a keyword, not a function, and should stand clear as a keyword. Syntax highlighting editors generally show keywords in a different colour from function names, and if I am writing code on paper I underline keywords as highlighting. I believe the spacing in "if (a == 2)" better reflects how parts of that code hang together. (For even better typography, I might prefer shorter spaces around the "==" than after the "if", but monospace fonts have their limitations.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-06 04:33 -0700 |
| Message-ID | <deab25e8-6ce3-4fc2-b8c4-b5568cedf81e@googlegroups.com> |
| In reply to | #61597 |
On Wednesday, May 6, 2015 at 8:34:42 AM UTC+1, David Brown wrote:
> On 05/05/15 16:01, Tim Rentsch wrote:
>
> You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ? "If" is a
> keyword, not a function, and should stand clear as a keyword. Syntax
> highlighting editors generally show keywords in a different colour from
> function names, and if I am writing code on paper I underline keywords
> as highlighting. I believe the spacing in "if (a == 2)" better reflects
> how parts of that code hang together. (For even better typography, I
> might prefer shorter spaces around the "==" than after the "if", but
> monospace fonts have their limitations.)
>
This seems to be the consensus.
I don't really understand myself. C only has a handful of keywords, one of which,
sizeof, is effectively a function. I never "see" for, if while and switch as anything
other than flow control.
Admittedly my coding style is to make a function call the only thing on a line,
where possible. So I rarely employ if( test_positive(x) ) {} or other mixtures of
calls with flow control.
If it's important to other people to have space between the if and the parenthesis,
then I don't mind doing it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-06 13:51 +0100 |
| Message-ID | <mid2n4$trt$2@dont-email.me> |
| In reply to | #61606 |
On 06/05/15 12:33, Malcolm McLean wrote:
> On Wednesday, May 6, 2015 at 8:34:42 AM UTC+1, David Brown wrote:
>> On 05/05/15 16:01, Tim Rentsch wrote:
>>
>> You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ? "If" is a
>> keyword, not a function, and should stand clear as a keyword. Syntax
>> highlighting editors generally show keywords in a different colour from
>> function names, and if I am writing code on paper I underline keywords
>> as highlighting. I believe the spacing in "if (a == 2)" better reflects
>> how parts of that code hang together. (For even better typography, I
>> might prefer shorter spaces around the "==" than after the "if", but
>> monospace fonts have their limitations.)
>>
> This seems to be the consensus.
>
> I don't really understand myself. C only has a handful of keywords, one of which,
> sizeof, is effectively a function.
Er, no, it's an operator. If it were effectively a function, it couldn't
effectively do its job.
> I never "see" for, if while and switch as anything
> other than flow control.
Neither do I. I see no value in adding the space.
> Admittedly my coding style is to make a function call the only thing on a line,
> where possible. So I rarely employ if( test_positive(x) ) {} or other mixtures of
> calls with flow control.
> If it's important to other people to have space between the if and the parenthesis,
> then I don't mind doing it.
I do mind adding the space, because then the code "looks wrong". But of
course that's a personal view, not a technical judgement.
--
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-07 11:51 -0700 |
| Message-ID | <kfnk2wkgr0t.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61608 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 06/05/15 12:33, Malcolm McLean wrote:
>> On Wednesday, May 6, 2015 at 8:34:42 AM UTC+1, David Brown wrote:
>>> [In response to a comment from Tim Rentsch]
>>>
>>> You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ? "If" is a
>>> keyword, not a function, and should stand clear as a keyword. Syntax
>>> highlighting editors generally show keywords in a different colour from
>>> function names, and if I am writing code on paper I underline keywords
>>> as highlighting. I believe the spacing in "if (a == 2)" better reflects
>>> how parts of that code hang together. (For even better typography, I
>>> might prefer shorter spaces around the "==" than after the "if", but
>>> monospace fonts have their limitations.)
>>
>> This seems to be the consensus.
>>
>> I don't really understand myself. [snip re: sizeof]
>>
>> I never "see" for, if while and switch as anything
>> other than flow control.
>
> Neither do I. I see no value in adding the space.
Which space are you talking about? Or do you mean you think
if()'s should be written with no spaces at all (not counting
spaces strictly inside the condition, of course)?
>> Admittedly my coding style is to make a function call the only thing on a line,
>> where possible. So I rarely employ if( test_positive(x) ) {} or other mixtures of
>> calls with flow control.
>> If it's important to other people to have space between the if and the parenthesis,
>> then I don't mind doing it.
>
> I do mind adding the space, because then the code "looks wrong". But
> of course that's a personal view, not a technical judgement.
Are you saying anything more than one looks worse than the other
because the better one is what you are used to? If so can you
say why or what that is?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-07 21:49 +0100 |
| Message-ID | <migj1v$sv3$1@dont-email.me> |
| In reply to | #61709 |
On 07/05/15 19:51, Tim Rentsch wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 06/05/15 12:33, Malcolm McLean wrote:
>>> On Wednesday, May 6, 2015 at 8:34:42 AM UTC+1, David Brown wrote:
>>>> [In response to a comment from Tim Rentsch]
>>>>
>>>> You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ? "If" is a
>>>> keyword, not a function, and should stand clear as a keyword. Syntax
>>>> highlighting editors generally show keywords in a different colour from
>>>> function names, and if I am writing code on paper I underline keywords
>>>> as highlighting. I believe the spacing in "if (a == 2)" better reflects
>>>> how parts of that code hang together. (For even better typography, I
>>>> might prefer shorter spaces around the "==" than after the "if", but
>>>> monospace fonts have their limitations.)
>>>
>>> This seems to be the consensus.
>>>
>>> I don't really understand myself. [snip re: sizeof]
>>>
>>> I never "see" for, if while and switch as anything
>>> other than flow control.
>>
>> Neither do I. I see no value in adding the space.
>
> Which space are you talking about?
To be as clear as possible, I mean that I prefer this:
if(foo)
{
while(i < n)
{
for(x = 0; x < maxx; x++)
{
switch(zog)
{
and am not at all keen on:
if (foo)
{
while (i < n)
{
for (x = 0; x < maxx; x++)
{
switch (zog)
{
>>> If it's important to other people to have space between the if and the parenthesis,
>>> then I don't mind doing it.
>>
>> I do mind adding the space, because then the code "looks wrong". But
>> of course that's a personal view, not a technical judgement.
>
> Are you saying anything more than one looks worse than the other
> because the better one is what you are used to? If so can you
> say why or what that is?
Difficult one. I think you're right - it probably is simply because it's
what I'm used to. If I'd been brought up (so to speak) with the space,
I'd have accepted it without question.
I should add that I've changed quite a few habits over time:
void main -> int main (!)
char *argv[] -> char **argv
0x00 -> '\0'
sizeof(object) -> sizeof object
indents from 8 spaces to 4 to 3 back to 4 and then to 2
tabs-and-spaces to just spaces
(unlikely to be a complete list, but those are the ones I can think of
without spending ages on it).
Each of these seemed to me to have a logical pay-off, though. (And I
think only one of them was provoked by a clc discussion.) If I could see
a genuine benefit in adding a space to if, while, switch, etc, fine, but
I haven't seen a persuasive argument yet. (And it would have to be very
persuasive to get me to re-educate my fingers!)
--
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-11 13:22 -0700 |
| Message-ID | <kfn3832euff.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61724 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 07/05/15 19:51, Tim Rentsch wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 06/05/15 12:33, Malcolm McLean wrote:
>>>> On Wednesday, May 6, 2015 at 8:34:42 AM UTC+1, David Brown wrote:
>>>>> [In response to a comment from Tim Rentsch]
>>>>>
>>>>> You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ?
>>>>> "If" is a keyword, not a function, and should stand clear as a
>>>>> keyword. Syntax highlighting editors generally show keywords in
>>>>> a different colour from function names, and if I am writing code
>>>>> on paper I underline keywords as highlighting. I believe the
>>>>> spacing in "if (a == 2)" better reflects how parts of that code
>>>>> hang together. (For even better typography, I might prefer
>>>>> shorter spaces around the "==" than after the "if", but
>>>>> monospace fonts have their limitations.)
>>>>
>>>> This seems to be the consensus.
>>>>
>>>> I don't really understand myself. [snip re: sizeof]
>>>>
>>>> I never "see" for, if while and switch as anything
>>>> other than flow control.
>>>
>>> Neither do I. I see no value in adding the space.
>>
>> Which space are you talking about?
>
> To be as clear as possible, I mean that I prefer this:
>
> if(foo)
> {
> while(i < n)
> {
> for(x = 0; x < maxx; x++)
> {
> switch(zog)
> {
>
> and am not at all keen on:
>
> if (foo)
> {
> while (i < n)
> {
> for (x = 0; x < maxx; x++)
> {
> switch (zog)
> {
>
Good, thank you for the clear expression.
>>>> If it's important to other people to have space between the if
>>>> and the parenthesis, then I don't mind doing it.
>>>
>>> I do mind adding the space, because then the code "looks wrong".
>>> But of course that's a personal view, not a technical judgement.
>>
>> Are you saying anything more than one looks worse than the other
>> because the better one is what you are used to? If so can you
>> say why or what that is?
>
> Difficult one. I think you're right - it probably is simply
> because it's what I'm used to. If I'd been brought up (so to
> speak) with the space, I'd have accepted it without question.
Something I do from time to time is deliberately adopt different
style choices, and live with them for a while, to counteract this
effect (meaning both avoiding lockin and to help discover other
choices that might be an improvement). Sort of a development
process version of simulated thermal annealing.
> I should add that I've changed quite a few habits over time:
>
> void main -> int main (!)
> char *argv[] -> char **argv
> 0x00 -> '\0'
> sizeof(object) -> sizeof object
> indents from 8 spaces to 4 to 3 back to 4 and then to 2
> tabs-and-spaces to just spaces
>
> (unlikely to be a complete list, but those are the ones I can think of
> without spending ages on it).
Interesting list. If I have time later I might try to come up with a
similar list for myself.
> Each of these seemed to me to have a logical pay-off, though.
> (And I think only one of them was provoked by a clc discussion.)
> If I could see a genuine benefit in adding a space to if, while,
> switch, etc, fine, but I haven't seen a persuasive argument yet.
I find this statement very interesting in the context of talking
about readability. Very often I find that the things that matter
do not come from logical reasoning but from noticing my behavior
when I actually read something. The first time I remember this
happening (ie, consciously) is reading a book typeset with TeX in
Computer Modern Roman. Normally I enjoy reading technical books,
but in this case I found myself getting impatient. By noticing
the effect I was able to introspect into what was causing the
reaction (too much to explain here). Having gone through that
experience, I am more sensitive to similar occurrences in writing
program code.
> (And it would have to be very persuasive to get me to re-educate
> my fingers!)
Yes, that's an energy barrier, for sure. That's one reason why I
force myself to try different choices, because I'm too good at
finding convincing arguments that they're stupid. :)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-06 15:27 +0100 |
| Message-ID | <87twvpaihi.fsf@bsb.me.uk> |
| In reply to | #61606 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, May 6, 2015 at 8:34:42 AM UTC+1, David Brown wrote:
>> On 05/05/15 16:01, Tim Rentsch wrote:
>>
>> You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ? "If" is a
>> keyword, not a function, and should stand clear as a keyword. Syntax
>> highlighting editors generally show keywords in a different colour from
>> function names, and if I am writing code on paper I underline keywords
>> as highlighting. I believe the spacing in "if (a == 2)" better reflects
>> how parts of that code hang together. (For even better typography, I
>> might prefer shorter spaces around the "==" than after the "if", but
>> monospace fonts have their limitations.)
>>
> This seems to be the consensus.
>
> I don't really understand myself. C only has a handful of keywords,
You have large hands. I count 44. It's still 33 even if you reject all
the new ones.
> one of which,
> sizeof, is effectively a function.
It's an operator (as you know). Why would you want to confuse people by
saying it's effectively something it isn't? I would not work if it were
a function. Even the syntax for using it would be different if it were
a function.
> I never "see" for, if while and
> switch as anything
> other than flow control.
> Admittedly my coding style is to make a function call the only thing on a line,
> where possible. So I rarely employ if( test_positive(x) ) {} or other mixtures of
> calls with flow control.
I find that extraordinary. Presumably you have no problem with writing
compound expressions in a test, and yet you avoid what is probably the
single most useful form of compound expression? Do you permit calls if
they are parts of more complex expressions (i.e. would "if(
!test_positive(x) )" or "if( l < strlen(s) )" be OK)?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-06 09:11 -0700 |
| Message-ID | <88f5e02e-fb63-427c-be33-f6a62d40c44b@googlegroups.com> |
| In reply to | #61610 |
On Wednesday, May 6, 2015 at 3:28:05 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > Admittedly my coding style is to make a function call the only thing on a line,
> > where possible. So I rarely employ if( test_positive(x) ) {} or other mixtures of
> > calls with flow control.
>
> I find that extraordinary. Presumably you have no problem with writing
> compound expressions in a test, and yet you avoid what is probably the
> single most useful form of compound expression? Do you permit calls if
> they are parts of more complex expressions (i.e. would "if(
> !test_positive(x) )" or "if( l < strlen(s) )" be OK)?
>
I permit them, I don't have a rigorous policy of excluding code like
if (l < strlen(s))
s[l] = 'x';
but I tend to find that if you're calling strlen(s) for one test, you'll likely
need to call it again for another purpose pretty soon.
So it's easier to write
int len = strlen(s);
if(l < len)
I like every line to be simple.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-06 21:00 +0100 |
| Message-ID | <87fv79a32m.fsf@bsb.me.uk> |
| In reply to | #61617 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, May 6, 2015 at 3:28:05 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> > Admittedly my coding style is to make a function call the only thing on a line,
>> > where possible. So I rarely employ if( test_positive(x) ) {} or
>> > other mixtures of
>> > calls with flow control.
>>
>> I find that extraordinary. Presumably you have no problem with writing
>> compound expressions in a test, and yet you avoid what is probably the
>> single most useful form of compound expression? Do you permit calls if
>> they are parts of more complex expressions (i.e. would "if(
>> !test_positive(x) )" or "if( l < strlen(s) )" be OK)?
>>
> I permit them, I don't have a rigorous policy of excluding code like
>
> if (l < strlen(s))
> s[l] = 'x';
>
> but I tend to find that if you're calling strlen(s) for one test, you'll likely
> need to call it again for another purpose pretty soon.
> So it's easier to write
>
> int len = strlen(s);
>
> if(l < len)
>
> I like every line to be simple.
But if( test_positive(x) ) is simpler than if( !test_positive(x) ). In
fact the form you avoid is the simplest possible expression involving a
function call.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-07 00:20 -0700 |
| Message-ID | <8d6ab44e-7179-4937-890a-91ba75c1e368@googlegroups.com> |
| In reply to | #61641 |
On Wednesday, May 6, 2015 at 9:00:59 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > if(l < len) > > > > I like every line to be simple. > > But if( test_positive(x) ) is simpler than if( !test_positive(x) ). In > fact the form you avoid is the simplest possible expression involving a > function call. > Depends what you mean. In one sense, it's a simple expression. In another sense, it's a complex construct, since it's both executing a subroutine call and deciding a conditional branch. if we write res = test_positive(x); if(res) then we've broken up the functionality. If the test is wrong, res will be an unexpected value, we can print it out. If the branch is wrong, then it's not because test_positive is returning the wrong result, it's because we need to invert the condition. I will admit that I break the rule for a few very trivial functions like sign() or max().
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-06 10:43 -0700 |
| Message-ID | <e4758694-7a21-4be4-8195-ab0f1fcba89b@googlegroups.com> |
| In reply to | #61610 |
On Wednesday, May 6, 2015 at 7:28:05 AM UTC-7, Ben Bacarisse wrote: > > I don't really understand myself. C only has a handful of keywords, > > You have large hands. I count 44. It's still 33 even if you reject all > the new ones. If you look at each word, symbol and symbol combination as a token (outside of strings) then C90 has 78 built in tokens. A compiler should have a tokenizer at its front end so all it sees is tokens. Sizeof is just another token at the same level as, say, &.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-06 13:11 -0700 |
| Message-ID | <87egmtlb3n.fsf@kst-u.example.com> |
| In reply to | #61632 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, May 6, 2015 at 7:28:05 AM UTC-7, Ben Bacarisse wrote:
>> > I don't really understand myself. C only has a handful of keywords,
>>
>> You have large hands. I count 44. It's still 33 even if you reject all
>> the new ones.
>
> If you look at each word, symbol and symbol combination as a token (outside
> of strings) then C90 has 78 built in tokens. A compiler should have a
> tokenizer at its front end so all it sees is tokens. Sizeof is just
> another token at the same level as, say, &.
C90 has 32 keywords, C99 has 37, and C11 has 44.
I'm not sure what relevance those numbers have. Malcolm's claim
upthread that the `sizeof` keyword "is effectively a function" is
incorrect. It's an operator. It happens to be the only operator
whose name is a keyword rather than a symbol. If you use other
languages that have more operators like that, you'll get used to it.
For example, several languages use `rem` and/or `mod` in place of
C's `%`.
Similarly, you might think of `return` as a function if you
habitually parenthesize the expression. That's one reason I avoid
doing that.
(A digression: The form of `sizeof` that applies to a parenthesized
type name isn't something I'd call an operator, since its "operand"
isn't a expression. I'd call it a special form of expression,
disinct from the `sizeof expr` form. But the standard calls it a
unary operator in both forms, so I'll go along with it.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-06 19:48 -0700 |
| Message-ID | <kfnsib9gl0w.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61642 |
Keith Thompson <kst-u@mib.org> writes: > (A digression: The form of `sizeof` that applies to a parenthesized > type name isn't something I'd call an operator, since its "operand" > isn't a expression. I'd call it a special form of expression, > disinct from the `sizeof expr` form. But the standard calls it a > unary operator in both forms, so I'll go along with it.) IMO it's better in this context to think of a type-name as an unusual form of operand. Also, you might want to consider, eg, 'sizeof (int[ n++ ])', where evaluating the type-name has semantic consequences.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-07 11:51 -0700 |
| Message-ID | <9a438218-b537-4212-9b82-a3616481ba27@googlegroups.com> |
| In reply to | #61661 |
On Wednesday, May 6, 2015 at 7:48:57 PM UTC-7, Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > > > (A digression: The form of `sizeof` that applies to a parenthesized > > type name isn't something I'd call an operator, since its "operand" > > isn't a expression. I'd call it a special form of expression, > > disinct from the `sizeof expr` form. But the standard calls it a > > unary operator in both forms, so I'll go along with it.) > > IMO it's better in this context to think of a type-name as an > unusual form of operand. > > Also, you might want to consider, eg, 'sizeof (int[ n++ ])', where > evaluating the type-name has semantic consequences. I assume you mean "if you treat sizeof as a function". As I understand it all that matters in a "sizeof (...) is the type of the value in .... The "n++" should be ignored.
[toc] | [prev] | [next] | [standalone]
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web