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 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-03 09:11 -0700 |
| Message-ID | <kfnpp6hmyjt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61359 |
asetofsymbols@gmail.com writes: > Tim wrote: >> I think I see what you're getting at - that it helps having and >> using a library that provides a core set of standard operations, >> relatively few in number but which provide powerful capabilities >> both individually and in combination. Is this what you mean? > > Yes, especially "in combination" Okay, thank you for the amplification.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-16 00:19 -0700 |
| Message-ID | <56791025-25ee-4467-af2e-a7be539128d1@googlegroups.com> |
| In reply to | #60096 |
On Wednesday, April 15, 2015 at 7:46:54 PM UTC+1, Tim Rentsch wrote: > > To start things going, some general questions. What are > different kinds, or different aspects, of readability? Do > different aspects interact, or are they mostly independent? What > habits, or development practices, or guidelines, or rules of > thumb, etc, would you suggest to promote readability? Can the > general term "readability" be subdivided into more specialized > areas in a useful way? How are conflicts resolved? To ask this > another way, what are the relative priorities of different > factors that go into making code readable? And to broaden the > topic, how do matters of readability relate to other concerns in > the development process (eg, maintenance, testing, etc)? > I think you've often got contradictory pressures. For example, long variable names are more descriptive, but they tend to make expressions harder to read. So you want number_of_employees = 100 but for(i=0; i<N/2;i++) swap(&employee[i], &employee[N-i-1]); Another issue is that a bit of punctuation, highlighting, and so on makes something easier to read, but once it goes above a certain limit, it starts to become harder to read. So a + (b * c); is easier on the eye than a + b * c but a*(1-t)*(1-t)*(1-t) + 3*b*(1-t)*(1-t)*t + 3*c*(1-t)*t*t + d*t*t*t is easier than (a*(1-t)*(1-t)*(1-t)) + (3*b*(1-t)*(1-t)*t) + (3*c*(1-t)*t*t) + (d*t*t*t)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-30 02:51 -0700 |
| Message-ID | <kfnlhhaaqqh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60116 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, April 15, 2015 at 7:46:54 PM UTC+1, Tim Rentsch wrote: > >> To start things going, some general questions. What are >> different kinds, or different aspects, of readability? Do >> different aspects interact, or are they mostly independent? What >> habits, or development practices, or guidelines, or rules of >> thumb, etc, would you suggest to promote readability? Can the >> general term "readability" be subdivided into more specialized >> areas in a useful way? How are conflicts resolved? To ask this >> another way, what are the relative priorities of different >> factors that go into making code readable? And to broaden the >> topic, how do matters of readability relate to other concerns in >> the development process (eg, maintenance, testing, etc)? > > I think you've often got contradictory pressures. [snip examples] Sure. And now the question is, what guidelines (specific, please, not general or abstract) give good results when opposing forces need resolution? (I appreciate the examples btw, just didn't have anything to say about them.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-30 20:14 -0700 |
| Message-ID | <a05a4353-aa3a-41c1-86a2-edeb4ad09c54@googlegroups.com> |
| In reply to | #61298 |
On Thursday, April 30, 2015 at 10:51:44 AM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > I think you've often got contradictory pressures. [snip examples] > > Sure. And now the question is, what guidelines (specific, > please, not general or abstract) give good results when > opposing forces need resolution? > > (I appreciate the examples btw, just didn't have anything > to say about them.) > It helps to know what the code is doing. Is it updating the UI, accessing a device at a low level, performing business or application logic, doing mathematics, doing graph work? If there isn't a clear answer, that's your first sign that something is wrong. If you're doing maths, it's best to use short identifiers like N, x, theta, which is the mathematical convention. If you're doing business logic, it's better to use long identifiers, because the logic is intimately driven by what the data means, and it's easy to mix up Nemployees (number of individuals employed) with Nstaff (number of full time equivalent workers assigned to something). However you don't want to go above two part names. If a name of a data item consists of more than two English words, it's too long. It's also best to keep structures and struct members to one word, which enables an natural two-part name. However that's not always possible if the member has an ambiguous name. Then when writing functions that operate on an opaque structure, it's best to keep the structure pointer argument very short, ideally one or two letters. But there aren't hard and fast rules. If a reader wants the gist of what a function is doing, he prefers long names. If he's got to read the expressions to see if they are correct / understand the logic, then he prefers short names. You can't provide both at the same time.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-01 05:10 -0700 |
| Message-ID | <kfnsibgo5wl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61342 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, April 30, 2015 at 10:51:44 AM UTC+1, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> I think you've often got contradictory pressures. [snip examples]
>>
>> Sure. And now the question is, what guidelines (specific,
>> please, not general or abstract) give good results when
>> opposing forces need resolution?
>>
>> (I appreciate the examples btw, just didn't have anything
>> to say about them.)
>
> It helps to know what the code is doing.
> Is it updating the UI, accessing a device at a low level,
> performing business or application logic, doing mathematics,
> doing graph work? If there isn't a clear answer, that's your
> first sign that something is wrong.
> If you're doing maths, it's best to use short identifiers like
> N, x, theta, which is the mathematical convention. If you're
> doing business logic, it's better to use long identifiers,
> because the logic is intimately driven by what the data means,
> and it's easy to mix up Nemployees (number of individuals
> employed) with Nstaff (number of full time equivalent workers
> assigned to something).
>
> However you don't want to go above two part names. If a name
> of a data item consists of more than two English words, it's
> too long. It's also best to keep structures and struct members
> to one word, which enables an natural two-part name. However
> that's not always possible if the member has an ambiguous name.
>
> Then when writing functions that operate on an opaque
> structure, it's best to keep the structure pointer argument
> very short, ideally one or two letters.
Okay. Not sure I agree with all these suggestions, but I
think I understand what the suggestions are.
> But there aren't hard and fast rules. If a reader wants the
> gist of what a function is doing, he prefers long names. If
> he's got to read the expressions to see if they are correct /
> understand the logic, then he prefers short names. You can't
> provide both at the same time.
Here are some possible choices (by design mutually exclusive):
(a) Use a very short name (eg, one or two letters);
(b) Use a very short name, with a comment giving a more complete
description;
(c) For a parameter, use a descriptive (eg, one English word)
name in the prototype, but immediately assign to a very
short name at the top of the function body, and use the
very short name in the function body;
(d) Use a short descriptive name (eg, one English word);
(e) Use a short descriptive name, with a comment giving a
full description;
(f) Use a more completely descriptive name (eg, two or more
English words);
(g) (and I expect there are others that have been left out).
My question again is how should tension between different
alternatives be resolved? Obviously only one alternative
can be chosen, since they are mutually exclusive. What
considerations are important, and what approximately are
the relative weights of the different considerations?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-01 06:10 -0700 |
| Message-ID | <5df638cc-1a9a-4dac-a6c4-26beb8426079@googlegroups.com> |
| In reply to | #61350 |
On Friday, May 1, 2015 at 1:10:12 PM UTC+1, Tim Rentsch wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > But there aren't hard and fast rules. If a reader wants the
> > gist of what a function is doing, he prefers long names. If
> > he's got to read the expressions to see if they are correct /
> > understand the logic, then he prefers short names. You can't
> > provide both at the same time.
>
> Here are some possible choices (by design mutually exclusive):
>
> (a) Use a very short name (eg, one or two letters);
>
> (b) Use a very short name, with a comment giving a more complete
> description;
>
> (c) For a parameter, use a descriptive (eg, one English word)
> name in the prototype, but immediately assign to a very
> short name at the top of the function body, and use the
> very short name in the function body;
>
> (d) Use a short descriptive name (eg, one English word);
>
> (e) Use a short descriptive name, with a comment giving a
> full description;
>
> (f) Use a more completely descriptive name (eg, two or more
> English words);
>
> (g) (and I expect there are others that have been left out).
>
> My question again is how should tension between different
> alternatives be resolved? Obviously only one alternative
> can be chosen, since they are mutually exclusive. What
> considerations are important, and what approximately are
> the relative weights of the different considerations?
>
I dislike block scope variables (but that's a separate issue to variable
naming).
So a C function written in my style has a list of all the variables it
uses, right at the top of the function. So you can naturally add
comments describing what each variable means. Although in
the nature of things, the variables vary during the function ("total"
will be initialised to zero, and not actually hold a total until a loop
is completed).
As I said, it depends what the function is doing. If the code is performing
some non-trivial mathematical calculation, then usually it's important
that a reader can parse the expressions, which means using short, ideally
one letter variable names. If it's what I call "glue code" then it's more
important that the right data is moved to the right place, there might
be hundreds of items in scope, counting structure members, and one
letter names are no longer viable.
So for maths, I'd go for (a). If you need the comment (b), then maybe your
convention is wrong. I'm not calling for a war on comments, but people
should know that x is a real independent variable, y a real dependent
variable, theta a simple angle, rho a dihedral and so on. For non-maths
functions, (f), but with the stipulation that names shouldn't normally
be more than two words. For graph-type functions, normally (e), you
need member variables like "next", "child", "prev" and so on.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-03 09:17 -0700 |
| Message-ID | <kfnlhh5my9o.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61351 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, May 1, 2015 at 1:10:12 PM UTC+1, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> But there aren't hard and fast rules. If a reader wants the
>>> gist of what a function is doing, he prefers long names. If
>>> he's got to read the expressions to see if they are correct /
>>> understand the logic, then he prefers short names. You can't
>>> provide both at the same time.
>>
>> Here are some possible choices (by design mutually exclusive):
>>
>> (a) Use a very short name (eg, one or two letters);
>>
>> (b) Use a very short name, with a comment giving a more complete
>> description;
>>
>> (c) For a parameter, use a descriptive (eg, one English word)
>> name in the prototype, but immediately assign to a very
>> short name at the top of the function body, and use the
>> very short name in the function body;
>>
>> (d) Use a short descriptive name (eg, one English word);
>>
>> (e) Use a short descriptive name, with a comment giving a
>> full description;
>>
>> (f) Use a more completely descriptive name (eg, two or more
>> English words);
>>
>> (g) (and I expect there are others that have been left out).
>>
>> My question again is how should tension between different
>> alternatives be resolved? Obviously only one alternative
>> can be chosen, since they are mutually exclusive. What
>> considerations are important, and what approximately are
>> the relative weights of the different considerations?
>
> I dislike block scope variables (but that's a separate issue to
> variable naming).
>
> So a C function written in my style has a list of all the
> variables it uses, right at the top of the function. So you can
> naturally add comments describing what each variable means.
> Although in the nature of things, the variables vary during the
> function ("total" will be initialised to zero, and not actually
> hold a total until a loop is completed).
>
> As I said, it depends what the function is doing. If the code is
> performing some non-trivial mathematical calculation, then usually
> it's important that a reader can parse the expressions, which
> means using short, ideally one letter variable names. If it's
> what I call "glue code" then it's more important that the right
> data is moved to the right place, there might be hundreds of items
> in scope, counting structure members, and one letter names are no
> longer viable.
>
> So for maths, I'd go for (a). If you need the comment (b), then
> maybe your convention is wrong. I'm not calling for a war on
> comments, but people should know that x is a real independent
> variable, y a real dependent variable, theta a simple angle, rho a
> dihedral and so on. For non-maths functions, (f), but with the
> stipulation that names shouldn't normally be more than two words.
> For graph-type functions, normally (e), you need member variables
> like "next", "child", "prev" and so on.
Well, that didn't really answer my question, but thank you for
the comments.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-16 11:01 +0200 |
| Message-ID | <mgntmq$g0q$1@dont-email.me> |
| In reply to | #60096 |
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! Consistency of style is more important than details of the style itself. 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. And don't break these rules in the name of size or speed of the target code. Make sure you have a good compiler, and know how to use it - and let the compiler generate the efficient target code. In a similar vein, don't try to "help" the compiler with "tricks" such as changing array expressions into pointer expressions - write the code in the clearest way, and let the compiler handle the optimisation.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-16 04:26 -0700 |
| Message-ID | <f2926dac-50a0-4edd-aff4-e133768c4ec6@googlegroups.com> |
| In reply to | #60121 |
On Thursday, April 16, 2015 at 10:01:17 AM UTC+1, David Brown wrote: > > And don't break these rules in the name of size or speed of the target > code. Make sure you have a good compiler, and know how to use it - and > let the compiler generate the efficient target code. In a similar vein, > don't try to "help" the compiler with "tricks" such as changing array > expressions into pointer expressions - write the code in the clearest > way, and let the compiler handle the optimisation. > There's often a tension between clarity and structure and performance. No so much peep-hole optimisations as caching intermediate results and stripping out reformatting, in my experience. Generally the former is more important. But sometimes you do need the performance. Nowadays, that tends to be in components written in C - you can use Perl or Python or something like that for the stuff that manages the filing system and the UI, but your core travelling salesman solution algorithm or whatever needs to be in C.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-16 13:19 -0500 |
| Message-ID | <mgoueh$9tv$1@dont-email.me> |
| In reply to | #60129 |
On 16-Apr-15 06:26, Malcolm McLean wrote: > On Thursday, April 16, 2015 at 10:01:17 AM UTC+1, David Brown wrote: >> In a similar vein, don't try to "help" the compiler with "tricks" >> such as changing array expressions into pointer expressions - write >> the code in the clearest way, and let the compiler handle the >> optimisation. >> > There's often a tension between clarity and structure and > performance. No so much peep-hole optimisations as caching > intermediate results and stripping out reformatting, in my > experience. One can leave the clear-but-slow implementation in place, and in debug builds, use its result to validate the fast-but-ugly implementation. In production builds, the clear-but-slow code would be #ifdef'd out for performance. 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-17 09:20 +0200 |
| Message-ID | <mgqc59$apo$1@dont-email.me> |
| In reply to | #60169 |
On 16/04/15 20:19, Stephen Sprunk wrote: > On 16-Apr-15 06:26, Malcolm McLean wrote: >> On Thursday, April 16, 2015 at 10:01:17 AM UTC+1, David Brown wrote: >>> In a similar vein, don't try to "help" the compiler with "tricks" >>> such as changing array expressions into pointer expressions - write >>> the code in the clearest way, and let the compiler handle the >>> optimisation. >>> >> There's often a tension between clarity and structure and >> performance. No so much peep-hole optimisations as caching >> intermediate results and stripping out reformatting, in my >> experience. > > One can leave the clear-but-slow implementation in place, and in debug > builds, use its result to validate the fast-but-ugly implementation. In > production builds, the clear-but-slow code would be #ifdef'd out for > performance. > That sounds dangerously like you are using different code for debugging and release, and that quickly leads to different code for /testing/ and release. You might not be going down the slippery slope yet, but you are definitely leaning over the edge! I am sure that /you/ know better, but many people make far too much difference between "debug" versions and "release" versions, with most of their testing done on the "debug" versions. It might boil down to exactly the same code in the end, but I would much rather think of it as the "fast-but-ugly" version is /the/ implementation for debugging, testing and release - but during debugging and testing you have extra inline tests using a clear-but-slow version.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-17 08:21 -0400 |
| Message-ID | <mgqtq5$7cc$1@dont-email.me> |
| In reply to | #60200 |
On 04/17/2015 03:20 AM, David Brown wrote: > On 16/04/15 20:19, Stephen Sprunk wrote: ... >> One can leave the clear-but-slow implementation in place, and in debug >> builds, use its result to validate the fast-but-ugly implementation. In >> production builds, the clear-but-slow code would be #ifdef'd out for >> performance. >> > > That sounds dangerously like you are using different code for debugging > and release, and that quickly leads to different code for /testing/ and > release. ... Reaching that conclusion requires ignoring the word "validate". The way he uses it implies testing both versions of the code, and comparing the results. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-17 15:04 +0200 |
| Message-ID | <mgr0ba$gi6$1@dont-email.me> |
| In reply to | #60224 |
On 17/04/15 14:21, James Kuyper wrote: > On 04/17/2015 03:20 AM, David Brown wrote: >> On 16/04/15 20:19, Stephen Sprunk wrote: > ... >>> One can leave the clear-but-slow implementation in place, and in debug >>> builds, use its result to validate the fast-but-ugly implementation. In >>> production builds, the clear-but-slow code would be #ifdef'd out for >>> performance. >>> >> >> That sounds dangerously like you are using different code for debugging >> and release, and that quickly leads to different code for /testing/ and >> release. ... > > Reaching that conclusion requires ignoring the word "validate". The way > he uses it implies testing both versions of the code, and comparing the > results. > If he hadn't used the word "validate", I would have been much stronger in my criticism - I understood what he meant. As I tried to explain in the second paragraph (which you snipped), my concern is about the way of thinking and the risk of falling for the temptation of having different "debug" and "release" code, rather than the suggested code itself.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-17 06:18 -0700 |
| Message-ID | <0da706e5-ea9d-460b-aacd-ff41796eaeaa@googlegroups.com> |
| In reply to | #60227 |
On Friday, April 17, 2015 at 2:04:45 PM UTC+1, David Brown wrote: > > If he hadn't used the word "validate", I would have been much stronger > in my criticism - I understood what he meant. As I tried to explain in > the second paragraph (which you snipped), my concern is about the way of > thinking and the risk of falling for the temptation of having different > "debug" and "release" code, rather than the suggested code itself. > A reference implementation is mainly for unit testing. Often the reference will be O(2^x) whilst the fast version will be polynomial, it's quite common to have problems where the brute force answer is trivial, the algorithm which scales quite hard to write. Sometimes it's appropriate to check the fast algorithm against the reference in debug builds, but often you want debug execution speed to bear some relation to runtime execution speed, and then, as you say, there's always the danger that you've somehow set a variable correctly from the reference version, but not overwritten it with the optimised version.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-17 12:24 -0500 |
| Message-ID | <mgrfjh$cq4$1@dont-email.me> |
| In reply to | #60200 |
On 17-Apr-15 02:20, David Brown wrote: > On 16/04/15 20:19, Stephen Sprunk wrote: >> On 16-Apr-15 06:26, Malcolm McLean wrote: >>> On Thursday, April 16, 2015 at 10:01:17 AM UTC+1, David Brown >>> wrote: >>>> In a similar vein, don't try to "help" the compiler with >>>> "tricks" such as changing array expressions into pointer >>>> expressions - write the code in the clearest way, and let the >>>> compiler handle the optimisation. >>>> >>> There's often a tension between clarity and structure and >>> performance. No so much peep-hole optimisations as caching >>> intermediate results and stripping out reformatting, in my >>> experience. >> >> One can leave the clear-but-slow implementation in place, and in >> debug builds, use its result to validate the fast-but-ugly >> implementation. In production builds, the clear-but-slow code >> would be #ifdef'd out for performance. > > That sounds dangerously like you are using different code for > debugging and release, ... I would much rather think of it as the > "fast-but-ugly" version is /the/ implementation for debugging, > testing and release - but during debugging and testing you have > extra inline tests using a clear-but-slow version. To clarify, in debug builds _both_ versions run, and the results are compared in an assert(). Assuming decent test cases, that should be sufficient to catch errors introduced while trying to optimize the fast-but-ugly version. 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 | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-04-17 15:58 +0000 |
| Message-ID | <W4aYw.461307$hv4.112745@fx04.iad> |
| In reply to | #60121 |
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.
auto_array* auto_array_create (size_t initial_size) {
auto_array* aa = malloc (sizeof (auto_array));
if (aa == NULL) {
PERR ("malloc");
return NULL;
}
aa->data = malloc (sizeof (void*) * initial_size);
if (aa->data == NULL) {
PERR ("malloc");
free (aa);
return NULL;
}
aa->size = initial_size;
aa->count = 0;
return aa;
}
For me there is enough space in the code that my eyes can see, in a
glance what is taking place, and yes, it is a very simple example but
much code is that simple and shouldn't require more then a glance to
understand.
> 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.
For instance, as a matter of preference I see no problem with both of
these styles co-existing:
auto_array *auto_array_create (size_t initial_size) {
auto_array* auto_array_create( size_t initial_size ) {
but am less sure about these:
auto_array *auto_array_create (size_t initial_size) {
auto_array *auto_array_create (size_t initial_size)
{
and am convinced these shouldn't be housed together:
auto_array *auto_array_create (size_t initial_size) {
auto_array *
auto_array_create (size_t initial_size)
{
In every shop there should be someone producing a style guideline,
written down or otherwise but code doesn't start life following such a
thing and not all programmers have come through the sort of training
that results in clear code so sometimes code styles have to co-exist, at
least for a period of time.
> 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.
i.e
char* buf;
/or/
for (int i = 0; i < some_size_variable; ++i) {
for (int ii = 0; ii < some_other_size_variable; ++ii) {
/or/
int num_written = 0;
char* pbuf = buf;
do {
int rv = write (fd, pbuf + num_written, buf_size - num_written);
if (rv <= 0) {
if (errno == EINTR) {
continue;
}
if (rv == 0) {
break;
}
int e = errno;
handle_error (e);
}
num_written += rv;
} while ((buf_size - num_written) != 0);
(rv is short for return value)
Hopefully I got the above code write, in any event, they are examples
that benefit from short variables, ones that are in common usage and
actually add to the readability by their shortness.
--
http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-30 04:10 -0700 |
| Message-ID | <kfn8ud9c1o3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60244 |
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." >> 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.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-30 13:47 +0200 |
| Message-ID | <mht4m8$nkp$1@dont-email.me> |
| In reply to | #61312 |
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). The exception, of course, is for the
"a==3" case above - don't copy that 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 heard a fine variant of the old joke recently: There are two sorts of
people - those that can extrapolate from limited information.)
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-30 13:48 +0100 |
| Message-ID | <mht88m$5o0$1@dont-email.me> |
| In reply to | #61316 |
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).
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.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-30 16:35 +0200 |
| Message-ID | <mhtehg$utl$1@dont-email.me> |
| In reply to | #61320 |
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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web