Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #87753 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2022-12-08 12:31 +0000 |
| Last post | 2023-01-04 00:22 -0800 |
| Articles | 20 on this page of 333 — 29 participants |
Back to article view | Back to comp.lang.c++
Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-08 12:31 +0000
Re: Overuse of 'auto' Bo Persson <bo@bo-persson.se> - 2022-12-08 15:25 +0100
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-08 15:48 +0000
Re: Overuse of 'auto' Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-12-08 19:29 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-09 15:52 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-09 12:52 +0000
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-09 05:03 -0800
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-09 14:15 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 06:59 +0000
Re: Overuse of 'auto' Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-12-17 16:53 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:32 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-08 07:59 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-09 12:56 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-09 07:57 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-09 17:44 +0000
Re: Overuse of 'auto' Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2022-12-09 21:01 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-09 20:47 +0000
Re: Overuse of 'auto' Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2022-12-10 14:48 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-10 21:52 +0000
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-11 00:29 +0100
Re: Overuse of 'auto' Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2022-12-11 14:37 +0100
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-12 09:35 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-11 16:42 +0100
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-09 13:07 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 07:14 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-12 08:54 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 11:31 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-12 16:11 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 15:59 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-12 17:17 +0000
Re: Overuse of 'auto' Ike Naar <ike@sdf.org> - 2022-12-12 22:02 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-12 22:41 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-12 16:00 -0800
Re: Overuse of 'auto' James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-13 02:48 -0500
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 00:03 -0800
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-13 14:39 +0200
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-13 14:10 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-13 14:59 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 13:07 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 08:24 +0000
Re: Overuse of 'auto' Udo Steinbach <trashcan@udoline.de> - 2022-12-14 17:50 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-14 17:13 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-14 20:01 +0200
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-14 18:12 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-12 10:25 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 08:32 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-13 01:11 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-13 14:31 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 13:42 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-13 09:42 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 10:20 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 11:10 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-13 15:58 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 06:23 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 07:36 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 09:43 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 12:19 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 16:24 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:35 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 14:11 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-14 12:17 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-15 08:53 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-16 21:41 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-17 15:34 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-17 13:27 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-17 13:32 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:58 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:46 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 14:55 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:24 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 22:03 +0200
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-19 20:38 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 22:54 +0200
Re: Overuse of 'auto' Tony Oliver <guinness.tony@gmail.com> - 2022-12-19 16:38 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 19:18 -0800
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-20 14:51 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 08:23 +0100
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-20 17:52 +0100
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-20 17:56 +0100
Re: Overuse of 'auto' Ralf Goertz <me@myprovider.invalid> - 2022-12-21 11:22 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 14:05 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:37 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 19:25 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:09 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:32 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 13:49 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 14:28 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 15:49 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 18:33 +0100
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-20 09:45 -0800
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-20 20:29 +0200
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 10:26 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 15:40 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 15:58 +0000
Re: Overuse of 'auto' Richard Damon <Richard@Damon-Family.org> - 2022-12-21 11:12 -0500
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 17:16 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-21 17:22 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 16:23 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 16:58 +0000
Re: Overuse of 'auto' Richard Damon <Richard@Damon-Family.org> - 2022-12-21 12:02 -0500
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 17:18 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-21 10:24 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:10 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 10:35 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:05 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 11:13 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:21 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 16:19 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:00 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 10:32 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:11 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 13:05 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 15:31 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-19 16:55 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 18:04 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 10:28 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 19:20 -0800
Re: Overuse of 'auto' red floyd <no.spam.here@its.invalid> - 2022-12-19 22:13 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 22:20 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 22:23 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:12 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 22:45 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:16 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-20 10:22 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:39 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 21:09 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:16 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-29 13:25 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-31 15:00 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-31 16:20 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-31 14:47 -0800
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-31 17:47 -0800
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-31 07:58 -0800
Re: Overuse of 'auto' Jack Lemmon <invalid@invalid.net> - 2022-12-31 18:03 +0000
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-31 14:46 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 06:24 +0000
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2023-01-03 01:49 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 10:05 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-03 10:14 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 11:04 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-03 15:20 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 07:23 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-03 23:29 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-03 23:30 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 01:41 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 08:35 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-04 22:48 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-05 09:14 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-05 16:34 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-06 13:02 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-06 14:31 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2023-01-05 16:48 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-06 13:18 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2023-01-06 16:45 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-09 05:17 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2023-01-09 00:45 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-09 13:26 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-10 05:56 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2023-01-09 22:48 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-10 11:08 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2023-01-10 03:28 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-10 16:26 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2023-01-10 07:48 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-10 09:11 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-10 17:16 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-10 21:38 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-10 12:48 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-11 05:47 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-11 09:21 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-13 07:51 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-13 10:14 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-13 12:45 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-13 14:08 +0000
Re: Overuse of 'auto' Daniel <danielaparker@gmail.com> - 2023-01-13 06:18 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-14 07:24 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-16 11:17 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-24 07:17 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-24 09:35 +0100
Re: Overuse of 'auto' Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-24 03:09 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-13 16:08 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-11 13:20 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-23 23:23 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-23 23:26 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-04 09:23 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 11:03 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-04 11:31 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 13:09 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-04 15:58 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2023-01-03 10:49 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-03 15:57 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:32 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 13:52 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 16:20 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:12 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-20 22:31 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:41 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 11:25 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:14 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 13:42 +0100
Re: Overuse of 'auto' Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-12-21 20:31 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-21 14:56 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-22 12:20 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-22 20:43 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-23 10:31 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-23 19:42 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 19:30 +0100
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 09:35 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 12:28 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 16:30 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-14 16:50 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 17:16 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 20:01 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:16 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-19 09:40 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 12:10 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 14:47 +0100
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-19 16:52 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 18:08 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 10:36 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:23 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-20 01:01 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:44 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-20 10:30 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 10:21 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:46 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 12:48 -0800
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-28 13:38 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:19 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 05:58 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 22:05 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 10:18 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:49 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 11:19 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 11:53 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 14:44 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:42 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:43 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 13:54 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-15 07:11 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:39 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-19 05:27 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:55 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-20 03:28 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 12:09 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-20 14:45 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 20:58 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:23 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-20 08:58 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:30 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-20 22:36 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 08:24 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 01:49 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 11:07 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 13:41 -0800
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 15:38 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-22 12:32 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-22 16:20 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-22 17:04 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-13 06:43 -0800
Re: Overuse of 'auto' Udo Steinbach <trashcan@udoline.de> - 2022-12-14 18:43 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 20:06 +0100
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-14 22:14 +0200
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-14 22:26 +0200
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-15 10:26 +0100
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-15 12:40 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:54 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:18 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-12 09:38 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-12 16:32 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-13 08:13 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-13 17:16 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-13 11:10 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 09:33 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 14:16 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:58 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:20 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-14 11:54 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-14 09:40 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-14 22:15 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-15 10:34 +0100
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-09 13:05 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 07:04 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 12:25 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:27 +0000
Re: Overuse of 'auto' Lynn McGuire <lynnmcguire5@gmail.com> - 2022-12-09 15:25 -0600
Re: Overuse of 'auto' Christian Gollwitzer <auriocus@gmx.de> - 2022-12-10 16:29 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-10 15:39 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 07:10 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-12 09:49 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 11:35 +0000
Re: Overuse of 'auto' Udo Steinbach <trashcan@udoline.de> - 2022-12-14 20:03 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 20:18 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 09:06 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:39 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-19 07:10 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:46 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-20 07:10 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 18:39 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-20 11:20 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 16:03 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-11 14:31 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 16:04 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 00:33 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 17:13 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 17:25 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 01:47 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 17:48 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 19:47 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 19:51 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 19:53 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 20:08 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 11:38 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 13:09 -0800
Re: Overuse of 'auto' Christian Gollwitzer <auriocus@gmx.de> - 2022-12-15 22:29 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-15 18:29 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 08:38 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 14:23 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-14 08:36 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-14 23:25 -0800
Re: Overuse of 'auto' Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-12-17 21:01 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 09:15 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:48 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 16:06 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 19:11 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 21:09 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:35 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 23:11 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 23:12 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 07:22 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 23:39 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 01:59 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:19 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:22 -0800
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-19 14:05 +0100 |
| Message-ID | <tnpniq$a6uo$1@dont-email.me> |
| In reply to | #88025 |
On 19/12/2022 08:46, Juha Nieminen wrote: > David Brown <david.brown@hesbynett.no> wrote: >> I use "using" locally in functions when it makes code simpler and >> clearer, because it makes names shorter and has less clutter. > > And there we go again with the brevity argument. Again, and again, and > again, and again. Ad infinitum. > I can't help it if it is true that shorter names are easier to read than longer names, as long as they are unambiguous in the context. Shorter names are easier to read, and faster to interpret. They have lower cognitive load. It uses less brainpower to read "i" and "x" than "loop_index" and "current_value". Less effort means fewer mistakes, and more of your brain's "bandwidth" is available for more important aspects of the task of understanding the code. So no matter how often /you/ repeat your unfounded assertions than short names and short code is inherently bad, you will still be wrong. > Sorter code is not necessarily clearer code. For a person that is so concerned about reading and understanding code, you are doing a rather poor job of reading and understanding people's posts in this thread. /No one/ has made any suggestion that "shorter code is /necessarily/ clearer". We have said that when the purpose of the identifier is unambiguous, /then/ a shorter identifier is clearer. Please tell me you understand the difference. > > The brevity-over-clarity style of programming will probably be a curse > in programming for as long as humanity will exist and keep writing > programs. /No one/ is promoting "bevity-over-clarity". We are arguing for "clarity-over-length". Yes, there are bad programmers out there, coming up with all sorts of new ways to annoy the people that have to look at their code. A few of them will think shorter names are always clearer - far more will use short names without regard to clarity. Others will use overly long names in a mistaken believe that long identifiers always make code easier to understand, just as some believe that copious comments are helpful by sheer quantity, rather than quality. > >> It also >> makes it clearer that I am "using" a particular imported namespace. > > Do you know what makes it even clearer? Saying so in the names from that > namespace. The reader doesn't have to guess when it's explicitly stated. > If the user is guessing, you're doing things wrong. > I will never understand why so many programmers fight tooth and nail > against this concept. Then I guess you'll never understand how almost all programmers work. And I'll never understand why you are obsessed with the illusion - as it /is/ an illusion - that code can be understood line by line, or that it is advantageous to do so. > >> If >> I have a namespace called "display", and I am writing a function that >> uses the display, it is a /good/ thing to write "using namespace >> display;" in that function. It is a /good/ thing to write "clear();" or >> "get_dimensions()" rather than "display::clear();" and >> "display::get_dimensions()". > > I see absolutely nothing "good" about it. I can only see negatives. > > How would I know what the 'clear()' is doing, or where it comes from? You'd know because it is obvious from the code if you dare to look at it. > Maybe it's clearing the data structures of this class? How would I know? > > You seem completely unable to position yourself in the shoes of a > third-party reading your code. > Sorry, but again you are /completely/ wrong. Take a book off your shelf. Open it at random. Pick a sentence half-way down the page. Do you really expect to be able to understand everything that is going on in that sentence from the sentence alone? Of course you don't. Why would you expect to do so in code? I expect code to be clear and understandable - in /appropriately/ sized units. I expect people to understand a little by reading just one line. I expect them to understand far more by reading a function. And yet more by looking at the class as a whole. And so on, up the hierarchy of classes, files, namespaces, libraries, etc. The last thing I would want to impose on someone reading my code is pointless repetition of information that is already clear - that just makes everything harder to read and comprehend. I really do not understand where your attitude comes from. It is contradictory to everything done in programming since the invention of the subroutine! You take a bit of code that is long enough to have meaning, and long enough to be an effort to understand at a glance, and you isolate it and give it a name that is short and easy to absorb in an instant. Then you use the short name instead of the long code. That is how we have named functions, named classes, named libraries, and everything else with names. And it is how we handle identifiers - long enough to be clear, but short enough to be readable and quickly understood within their context. Have you ever done any mathematics? Which do you think is clearer: "The height on the vertical axis is equal to the distance along the horizontal axis squared plus four times the distance along the horizontal access minus three", or "y = x² + 4x - 3" ? >> People don't like having to write long prefixes when it is obvious from >> the context of the code which library or set of identifiers you are >> using. > > But that's the problem: It may be obvious *to you*, the person writing > the code. It may be far from obvious to someone else who is reading your > code and doesn't know in advance what it's doing. When you specify the > prefixes you are helping the reader understand what that name is and > where it comes from. I don't care about the person writing the code. I care about the person /reading/ the code. I care that they can understand what the code does - that they can understand the /important/ aspects of the code. I don't want them to have to wade through endless repetitions of nested namespaces, or long sentences where a short identifier does the job better. I want them to be able to see what is going on as easily and as error-free as possible. No one is suggesting you have 50 line functions where the only variables are "int tmp1,tmp2,tmp3;" at the top of the function and then re-used for a dozen purposes - we all know there are people who write such code, and we all know it is incomprehensible and unmaintainable. Write short, clear functions and the variables can be short and clear. /Good/ names and identifiers are a key art in programming. But length or the use of whole words and phrases instead of short names and /obvious/ abbreviations is not a substitute for good naming. I'd certainly rather see "tmp" than "temporary_value".
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 15:37 +0000 |
| Message-ID | <tnq0fc$1ngq$1@gioia.aioe.org> |
| In reply to | #88041 |
David Brown <david.brown@hesbynett.no> wrote: > I can't help it if it is true that shorter names are easier to read than > longer names, as long as they are unambiguous in the context. Is that why you always use short words like "unambiguous", "cognitive", "brainpower" and "understanding"? A short name isn't really all that much easier to read than a long name. The problem with short names is that they don't convey as much information and they can make code more compressed, which means that there's a lot more information in a small space, making deciphering code that much more difficult. If you have difficulty in reading and understanding big words, well... there's a slightly offensive joke I could make about it. >>> If >>> I have a namespace called "display", and I am writing a function that >>> uses the display, it is a /good/ thing to write "using namespace >>> display;" in that function. It is a /good/ thing to write "clear();" or >>> "get_dimensions()" rather than "display::clear();" and >>> "display::get_dimensions()". >> >> I see absolutely nothing "good" about it. I can only see negatives. >> >> How would I know what the 'clear()' is doing, or where it comes from? > > You'd know because it is obvious from the code if you dare to look at it. Would be much more obvious if it actually said what it's "clearing". > Take a book off your shelf. Open it at random. Pick a sentence > half-way down the page. Do you really expect to be able to understand > everything that is going on in that sentence from the sentence alone? > Of course you don't. Why would you expect to do so in code? I certainly don't need to start checking the glossary of terms of the book every second word because it only uses obscure contractions and acronyms. But that's exactly the case with the majority of code out there. Even lines of code that *could* be clear on their own are made obfuscated by the use of cryptic abbreviations which hide the meaning. > Have you ever done any mathematics? Which do you think is clearer: "The > height on the vertical axis is equal to the distance along the > horizontal axis squared plus four times the distance along the > horizontal access minus three", or "y = x² + 4x - 3" ? Mathematics does not deal with strings, classes, algorithms, data containers, I/O, files, device drivers and so on and so forth. And it's mostly inscrutable anyway. Sometimes it feels like mathematicians take pride in making their work as incomprehensible to the uninitiated as humanly possible. > Write short, clear functions and the variables can be short and clear. > /Good/ names and identifiers are a key art in programming. But length > or the use of whole words and phrases instead of short names and > /obvious/ abbreviations is not a substitute for good naming. I'd > certainly rather see "tmp" than "temporary_value". Then use a better name if the long name does not convey clearly its purpose.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-19 19:25 +0100 |
| Message-ID | <tnqaba$diha$1@dont-email.me> |
| In reply to | #88054 |
On 19/12/2022 16:37, Juha Nieminen wrote: > David Brown <david.brown@hesbynett.no> wrote: >> I can't help it if it is true that shorter names are easier to read than >> longer names, as long as they are unambiguous in the context. > > Is that why you always use short words like "unambiguous", "cognitive", > "brainpower" and "understanding"? > If there were shorter words that meant the same and were equally familiar, I'd use them. (Assuming I thought of them at the time!) > A short name isn't really all that much easier to read than a long name. > The problem with short names is that they don't convey as much information > and they can make code more compressed, which means that there's a lot > more information in a small space, making deciphering code that much > more difficult. > Shorter names /are/ easier to read and understand, if they convey the same information. There's a certain amount of variation between people, however. Some people find it easier to read words if they can pronounce them in some way - others recognise words more visually. This means that some people will process "temp" faster than "tmp", while for others it does not make a difference. > If you have difficulty in reading and understanding big words, well... > there's a slightly offensive joke I could make about it. > >>>> If >>>> I have a namespace called "display", and I am writing a function that >>>> uses the display, it is a /good/ thing to write "using namespace >>>> display;" in that function. It is a /good/ thing to write "clear();" or >>>> "get_dimensions()" rather than "display::clear();" and >>>> "display::get_dimensions()". >>> >>> I see absolutely nothing "good" about it. I can only see negatives. >>> >>> How would I know what the 'clear()' is doing, or where it comes from? >> >> You'd know because it is obvious from the code if you dare to look at it. > > Would be much more obvious if it actually said what it's "clearing". It /is/ obvious what it is clearing - it's a function concerned with a display, and it has "using namespace display" in it. > >> Take a book off your shelf. Open it at random. Pick a sentence >> half-way down the page. Do you really expect to be able to understand >> everything that is going on in that sentence from the sentence alone? >> Of course you don't. Why would you expect to do so in code? > > I certainly don't need to start checking the glossary of terms of the > book every second word because it only uses obscure contractions and > acronyms. > If you have to do that when reading code, you are not ready to read that code. Making code readable and understandable does not mean making everything obvious in every line. If you want to understand a piece of /my/ code, I expect you to have done some basic homework first. You need to be aware of what the target system should do, have a rough understanding of the type of microcontroller being used, have read the comments at the start of the file, looked at the rest of the function, etc. There is a great deal more to know about code than what you see on a line, regardless of the names of the identifiers or the use of explicit namespaces. Perhaps you expect too much from people's code? You are looking to be spoon-feed on every line, regardless of how much worse the code is for people who want to have a better understanding of the code as a whole. > But that's exactly the case with the majority of code out there. Even > lines of code that *could* be clear on their own are made obfuscated > by the use of cryptic abbreviations which hide the meaning. > >> Have you ever done any mathematics? Which do you think is clearer: "The >> height on the vertical axis is equal to the distance along the >> horizontal axis squared plus four times the distance along the >> horizontal access minus three", or "y = x² + 4x - 3" ? > > Mathematics does not deal with strings, classes, algorithms, data > containers, I/O, files, device drivers and so on and so forth. > So? > And it's mostly inscrutable anyway. Sometimes it feels like mathematicians > take pride in making their work as incomprehensible to the uninitiated as > humanly possible. > Do you think insulting mathematicians makes your case stronger? It simply makes it clearer that you are on your own here, living in a different world from other developers. >> Write short, clear functions and the variables can be short and clear. >> /Good/ names and identifiers are a key art in programming. But length >> or the use of whole words and phrases instead of short names and >> /obvious/ abbreviations is not a substitute for good naming. I'd >> certainly rather see "tmp" than "temporary_value". > > Then use a better name if the long name does not convey clearly its > purpose.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-20 06:09 +0000 |
| Message-ID | <tnrji9$mdp$1@gioia.aioe.org> |
| In reply to | #88069 |
David Brown <david.brown@hesbynett.no> wrote: > If you have to do that when reading code, you are not ready to read that > code. > > Making code readable and understandable does not mean making everything > obvious in every line. If you want to understand a piece of /my/ code, > I expect you to have done some basic homework first. And here we come to the crux of the entire problem: You are writing the code for yourself, and expecting the reader to do the "homework" in order to understand it. The onus is on the reader to do the work to understand the code. Good code, however, does the opposite: The onus is on the *writer* to make it as easy for the reader to understand the code as possible. The work to make the code understandable is done by the writer, not the reader. > Perhaps you expect too much from people's code? You are looking to be > spoon-feed on every line, regardless of how much worse the code is for > people who want to have a better understanding of the code as a whole. It still baffles my mind how someone can think that making the code more understandable makes it less understandable. There's an amazing amount of cognitive dissonance here. Either you are... well, I don't want to be explicitly offensive... or you are just arguing for the sake of arguing. I'll give you the benefit of the doubt and assume the latter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-20 13:32 +0100 |
| Message-ID | <tnsa0t$mekd$2@dont-email.me> |
| In reply to | #88094 |
On 20/12/2022 07:09, Juha Nieminen wrote: > David Brown <david.brown@hesbynett.no> wrote: >> If you have to do that when reading code, you are not ready to read that >> code. >> >> Making code readable and understandable does not mean making everything >> obvious in every line. If you want to understand a piece of /my/ code, >> I expect you to have done some basic homework first. > > And here we come to the crux of the entire problem: You are writing the > code for yourself, and expecting the reader to do the "homework" in order > to understand it. The onus is on the reader to do the work to understand > the code. The onus is on the reader not to be an idiot! I'm sorry, but I don't write code with the expectation that it should be immediately readable and understandable by every kid who takes a cursory glance at it. I write my code so that other /programmers/ can use it in their code, understand it for code reviews, maintain it when I am not around, and otherwise read, understand and use the code. If some fool wants to come along and look at a single line, then go crying because they can't see exactly how everything works from the one line, then they can go cry elsewhere. Seriously, I have no sympathy for someone who expects the kind of spoon-feeding you seem to demand. You are just as bad as someone who thinks "t1" is fine for a global variable name because it is "obvious". Get real. Buy yourself a screen that can display a dozen lines of code at a time in one window, the file-level and function-level comments in another, and the program specification and documentation in another. Code must be understood from its context - not as lines standing alone. Variables, functions, types - they all live in an ecosystem, and if you want to understand some code, you need to put some effort into understanding that ecosystem. If the code can't be followed /despite/ knowing its ecosystem and wider context, or the context is incomprehensible, /then/ you have good grounds for complaint. And unfortunately there's plenty of code like that. > > Good code, however, does the opposite: The onus is on the *writer* to > make it as easy for the reader to understand the code as possible. The > work to make the code understandable is done by the writer, not the > reader. > Yes. You should try it some time. Writing code as though you are paid by character is not good enough. >> Perhaps you expect too much from people's code? You are looking to be >> spoon-feed on every line, regardless of how much worse the code is for >> people who want to have a better understanding of the code as a whole. > > It still baffles my mind how someone can think that making the code > more understandable makes it less understandable. There's an amazing > amount of cognitive dissonance here. > What baffles /me/ is that you think you have found a unique way to make code "understandable" and that everyone else, the world over, gets it wrong and is trying to undermine you. I'm not sure if it is paranoia or narcissism, but it is certainly not a good thing. Let's get this straight. /No one/ is saying it is good to make code "less understandable". I am saying that /your/ attempts at making code "easy to read" and "easy to understand" can be counter-productive and can make code /harder/ to read, /harder/ to understand, /less/ clear. At the risk of stating tautologies, overly long names, excessive identifiers, failure to use language facilities such as "using" and "auto" appropriately, all lead to code that is hard to understand. Is that so hard for you to comprehend? > Either you are... well, I don't want to be explicitly offensive... > or you are just arguing for the sake of arguing. I'll give you the > benefit of the doubt and assume the latter. I'm quite happy for you to say what you mean - I certainly do. (And I don't think it is offensive to do so - honest criticism is fine.)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-20 13:49 +0000 |
| Message-ID | <tnseh1$8j7$1@gioia.aioe.org> |
| In reply to | #88125 |
David Brown <david.brown@hesbynett.no> wrote: > Writing code as though you are paid > by character is not good enough. And here we go, once again, with the length argument. It doesn't matter how many times I repeat that it's not about the length, the same argument will still come up again, and again, and again, and again. Regardless of whether you are misunderstanding my point inadvertently or deliberately, this just goes to show that you outright don't *want* to understand nor acknowledge what I'm trying to say. In other words, you are just arguing in bad faith. > What baffles /me/ is that you think you have found a unique way to make > code "understandable" and that everyone else, the world over, gets it > wrong and is trying to undermine you. I'm not sure if it is paranoia or > narcissism, but it is certainly not a good thing. What the fuck are you talking about? Nowhere have I said or even implied that this is my own original idea that nobody else has ever had and nobody else knows or understands. I know lots of people who fully agree with these ideas. These ideas are pretty much as old as computer programming itself. I am merely recounting my own experiences on this and confirming the validity of these ideas. There are several people *in this very thread* who partially or fully agree with the title of the thread (ie. that the overuse of 'auto', which is sadly common, is detrimental to program readability). I know many people who think very similarly about variable and function naming. I wouldn't be surprised if very similar ideas couldn't be found in programming books and papers all the way back to the 70's and 60's. What I would actually find a bit surprising if there were books and papers arguing for the opposite, ie. what you are saying.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-20 14:28 +0000 |
| Message-ID | <tnsgqd$1e2s$1@gioia.aioe.org> |
| In reply to | #88128 |
Juha Nieminen <nospam@thanks.invalid> wrote: >> What baffles /me/ is that you think you have found a unique way to make >> code "understandable" and that everyone else, the world over, gets it >> wrong and is trying to undermine you. I'm not sure if it is paranoia or >> narcissism, but it is certainly not a good thing. > > What the fuck are you talking about? Nowhere have I said or even implied > that this is my own original idea that nobody else has ever had and > nobody else knows or understands. I know lots of people who fully agree > with these ideas. These ideas are pretty much as old as computer > programming itself. I am merely recounting my own experiences on this > and confirming the validity of these ideas. Out of curiosity, I searched for the coding guidelines of large companies out there in order to check what they say about variable and function naming, and most of them seem to broadly agree with what I have been saying here (with some exceptions). For example, Microsoft's coding guideline says: "DO choose easily readable identifier names. For example, a property named HorizontalAlignment is more English-readable than AlignmentHorizontal." "DO favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis)." "DO NOT use abbreviations or contractions as part of identifier names. For example, use GetWindow rather than GetWin." "DO NOT use any acronyms that are not widely accepted, and even if they are, only when necessary." I could have written that myself! Google's coding guidelines also has several points I agree with (and a few that I don't really): "Use names that describe the purpose or intent of the object. Do not worry about saving horizontal space as it is far more important to make your code immediately understandable by a new reader. Minimize the use of abbreviations that would likely be unknown to someone outside your project (especially acronyms and initialisms). Do not abbreviate by deleting letters within a word. As a rule of thumb, an abbreviation is probably OK if it's listed in Wikipedia." Again, I could have written that myself! So no, I do not think that I "have found a unique way to make code understandable". I'm merely confirming existing wisdom.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-20 15:49 +0000 |
| Message-ID | <tnsli3$1sci$1@gioia.aioe.org> |
| In reply to | #88132 |
On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >For example, Microsoft's coding guideline says: I doubt many people would take much notice on MS's opinion on coding. >"DO NOT use abbreviations or contractions as part of identifier names. >For example, use GetWindow rather than GetWin." Yet oddly at least 3 generations of unix devs have coped with abbreviated posix function names such as ioctl(), getuid(), uname() etc without struggling to understand the code. Not to mention standard C functions such as fopen().
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-20 18:33 +0100 |
| Message-ID | <tnsrlt$o8sf$1@dont-email.me> |
| In reply to | #88141 |
On 20/12/2022 16:49, Muttley@dastardlyhq.com wrote: > On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> For example, Microsoft's coding guideline says: > > I doubt many people would take much notice on MS's opinion on coding. > >> "DO NOT use abbreviations or contractions as part of identifier names. >> For example, use GetWindow rather than GetWin." > > Yet oddly at least 3 generations of unix devs have coped with abbreviated > posix function names such as ioctl(), getuid(), uname() etc without struggling > to understand the code. Not to mention standard C functions such as fopen(). > Despite my comments in this thread, even I would say that they could have used a /few/ more letters in some POSIX names! On the other hand, descriptive names with full words are arguably worse if the names don't fit. I remember from old Windows programming (it may have been early WinNT or even Win32s), there was an Windows API function called "OpenFile" that could be used to access a device, open a pipe, or all kinds of different things - pretty much /everything/ except open a file.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-20 09:45 -0800 |
| Message-ID | <1b6993f4-eb47-42ee-81da-cddfcdfba94fn@googlegroups.com> |
| In reply to | #88147 |
On Tuesday, 20 December 2022 at 19:34:04 UTC+2, David Brown wrote: > On 20/12/2022 16:49, Mut...@dastardlyhq.com wrote: > > On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) > > Juha Nieminen <nos...@thanks.invalid> wrote: > >> For example, Microsoft's coding guideline says: > > > > I doubt many people would take much notice on MS's opinion on coding. > > > >> "DO NOT use abbreviations or contractions as part of identifier names. > >> For example, use GetWindow rather than GetWin." > > > > Yet oddly at least 3 generations of unix devs have coped with abbreviated > > posix function names such as ioctl(), getuid(), uname() etc without struggling > > to understand the code. Not to mention standard C functions such as fopen(). > > > Despite my comments in this thread, even I would say that they could > have used a /few/ more letters in some POSIX names! > > On the other hand, descriptive names with full words are arguably worse > if the names don't fit. I remember from old Windows programming (it may > have been early WinNT or even Win32s), there was an Windows API function > called "OpenFile" that could be used to access a device, open a pipe, or > all kinds of different things - pretty much /everything/ except open a file. We all use standard library containers whose method empty() does something not related to emptying the container. Possibly we gained requirement of size() always being O(1) thanks to that bad naming. The if(c.empty()) feels like checking that emptying was successful so programmers kept comparing the size() with 0 for readability.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-20 20:29 +0200 |
| Message-ID | <tnsute$oct8$2@dont-email.me> |
| In reply to | #88141 |
20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: > On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> For example, Microsoft's coding guideline says: > > I doubt many people would take much notice on MS's opinion on coding. > >> "DO NOT use abbreviations or contractions as part of identifier names. >> For example, use GetWindow rather than GetWin." > > Yet oddly at least 3 generations of unix devs have coped with abbreviated > posix function names such as ioctl(), getuid(), uname() etc without struggling > to understand the code. Not to mention standard C functions such as fopen(). I recall the authors of those names are generally happy with them, except for one abbreviation: creat().
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-21 10:26 +0000 |
| Message-ID | <tnun09$mi3$1@gioia.aioe.org> |
| In reply to | #88153 |
On Tue, 20 Dec 2022 20:29:02 +0200 Paavo Helde <eesnimi@osa.pri.ee> wrote: >20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: >> On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >>> For example, Microsoft's coding guideline says: >> >> I doubt many people would take much notice on MS's opinion on coding. >> >>> "DO NOT use abbreviations or contractions as part of identifier names. >>> For example, use GetWindow rather than GetWin." >> >> Yet oddly at least 3 generations of unix devs have coped with abbreviated >> posix function names such as ioctl(), getuid(), uname() etc without >struggling >> to understand the code. Not to mention standard C functions such as fopen(). > >I recall the authors of those names are generally happy with them, >except for one abbreviation: creat(). Yes, that is a bit of an odd one. Perhaps they thought that "create" would be a name people would want to use a lot for their own function names.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-21 15:40 +0000 |
| Message-ID | <BNFoL.17268$rKDc.16496@fx34.iad> |
| In reply to | #88180 |
Muttley@dastardlyhq.com writes: >On Tue, 20 Dec 2022 20:29:02 +0200 >Paavo Helde <eesnimi@osa.pri.ee> wrote: >>20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: >>> On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) >>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>> For example, Microsoft's coding guideline says: >>> >>> I doubt many people would take much notice on MS's opinion on coding. >>> >>>> "DO NOT use abbreviations or contractions as part of identifier names. >>>> For example, use GetWindow rather than GetWin." >>> >>> Yet oddly at least 3 generations of unix devs have coped with abbreviated >>> posix function names such as ioctl(), getuid(), uname() etc without >>struggling >>> to understand the code. Not to mention standard C functions such as fopen(). >> >>I recall the authors of those names are generally happy with them, >>except for one abbreviation: creat(). > >Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >a name people would want to use a lot for their own function names. IIRC, "creat" actually came from the assembler version of the system call name.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-21 15:58 +0000 |
| Message-ID | <tnvafj$bri$1@gioia.aioe.org> |
| In reply to | #88194 |
On Wed, 21 Dec 2022 15:40:17 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >Muttley@dastardlyhq.com writes: >>On Tue, 20 Dec 2022 20:29:02 +0200 >>Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: >>>> On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) >>>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>> For example, Microsoft's coding guideline says: >>>> >>>> I doubt many people would take much notice on MS's opinion on coding. >>>> >>>>> "DO NOT use abbreviations or contractions as part of identifier names. >>>>> For example, use GetWindow rather than GetWin." >>>> >>>> Yet oddly at least 3 generations of unix devs have coped with abbreviated >>>> posix function names such as ioctl(), getuid(), uname() etc without >>>struggling >>>> to understand the code. Not to mention standard C functions such as >fopen(). >>> >>>I recall the authors of those names are generally happy with them, >>>except for one abbreviation: creat(). >> >>Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >>a name people would want to use a lot for their own function names. > >IIRC, "creat" actually came from the assembler version of the system call name. Still begs the question of why they left off the 'e'. Probably lost in the mists of time.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-21 11:12 -0500 |
| Message-ID | <1gGoL.49894$Tcw8.46248@fx10.iad> |
| In reply to | #88195 |
On 12/21/22 10:58 AM, Muttley@dastardlyhq.com wrote: > On Wed, 21 Dec 2022 15:40:17 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: >> Muttley@dastardlyhq.com writes: >>> On Tue, 20 Dec 2022 20:29:02 +0200 >>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>> 20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: >>>>> On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) >>>>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>>> For example, Microsoft's coding guideline says: >>>>> >>>>> I doubt many people would take much notice on MS's opinion on coding. >>>>> >>>>>> "DO NOT use abbreviations or contractions as part of identifier names. >>>>>> For example, use GetWindow rather than GetWin." >>>>> >>>>> Yet oddly at least 3 generations of unix devs have coped with abbreviated >>>>> posix function names such as ioctl(), getuid(), uname() etc without >>>> struggling >>>>> to understand the code. Not to mention standard C functions such as >> fopen(). >>>> >>>> I recall the authors of those names are generally happy with them, >>>> except for one abbreviation: creat(). >>> >>> Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >>> a name people would want to use a lot for their own function names. >> >> IIRC, "creat" actually came from the assembler version of the system call name. > > Still begs the question of why they left off the 'e'. Probably lost in the > mists of time. > I seem to have vague memories of some legacy system with 5 character external name limit. This could just be a name chosen to match what was used before.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-21 17:16 +0000 |
| Message-ID | <9cHoL.49896$Tcw8.6043@fx10.iad> |
| In reply to | #88196 |
Richard Damon <Richard@Damon-Family.org> writes: >On 12/21/22 10:58 AM, Muttley@dastardlyhq.com wrote: >> On Wed, 21 Dec 2022 15:40:17 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: >>> Muttley@dastardlyhq.com writes: >>>> On Tue, 20 Dec 2022 20:29:02 +0200 >>>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>>> 20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: >>>>>> On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) >>>>>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>>>> For example, Microsoft's coding guideline says: >>>>>> >>>>>> I doubt many people would take much notice on MS's opinion on coding. >>>>>> >>>>>>> "DO NOT use abbreviations or contractions as part of identifier names. >>>>>>> For example, use GetWindow rather than GetWin." >>>>>> >>>>>> Yet oddly at least 3 generations of unix devs have coped with abbreviated >>>>>> posix function names such as ioctl(), getuid(), uname() etc without >>>>> struggling >>>>>> to understand the code. Not to mention standard C functions such as >>> fopen(). >>>>> >>>>> I recall the authors of those names are generally happy with them, >>>>> except for one abbreviation: creat(). >>>> >>>> Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >>>> a name people would want to use a lot for their own function names. >>> >>> IIRC, "creat" actually came from the assembler version of the system call name. >> >> Still begs the question of why they left off the 'e'. Probably lost in the >> mists of time. >> > >I seem to have vague memories of some legacy system with 5 character >external name limit. This could just be a name chosen to match what was >used before. > I've seen folks refer to the 6 character unix linker limit, but the limit was 8 characters in the v6 compiler. Later compilers would prefix external symbols with an underscore, but that was long after creat was added to unix. Best I can tell, dropping the second 'e' from creat was simply to make it easier to type on a teletype.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-21 17:22 +0000 |
| Message-ID | <87sfh8u0wg.fsf@bsb.me.uk> |
| In reply to | #88196 |
Richard Damon <Richard@Damon-Family.org> writes: > On 12/21/22 10:58 AM, Muttley@dastardlyhq.com wrote: >> On Wed, 21 Dec 2022 15:40:17 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: >>> Muttley@dastardlyhq.com writes: >>>> On Tue, 20 Dec 2022 20:29:02 +0200 >>>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>>> 20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: >>>>>> On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) >>>>>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>>>> For example, Microsoft's coding guideline says: >>>>>> >>>>>> I doubt many people would take much notice on MS's opinion on coding. >>>>>> >>>>>>> "DO NOT use abbreviations or contractions as part of identifier names. >>>>>>> For example, use GetWindow rather than GetWin." >>>>>> >>>>>> Yet oddly at least 3 generations of unix devs have coped with abbreviated >>>>>> posix function names such as ioctl(), getuid(), uname() etc without >>>>> struggling >>>>>> to understand the code. Not to mention standard C functions such as >>> fopen(). >>>>> >>>>> I recall the authors of those names are generally happy with them, >>>>> except for one abbreviation: creat(). >>>> >>>> Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >>>> a name people would want to use a lot for their own function names. >>> >>> IIRC, "creat" actually came from the assembler version of the system call name. >> Still begs the question of why they left off the 'e'. Probably lost in the >> mists of time. >> > > I seem to have vague memories of some legacy system with 5 character > external name limit. This could just be a name chosen to match what > was used before. My recollection was of a limit of 6 characters, but external names had an _ added to the front of them making the limit effectively 5. However, that does not explain the missing e, since all systems I can recall allowed longer names -- they just ignored the extras. The limit explains short prefixes like the "f" for the file operations because file_open and file_close would both appear as _file_ to the linker, but it does not directly explain the missing e in creat. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-21 16:23 +0000 |
| Message-ID | <_pGoL.10793$Olad.7784@fx35.iad> |
| In reply to | #88195 |
Muttley@dastardlyhq.com writes: >On Wed, 21 Dec 2022 15:40:17 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: >>Muttley@dastardlyhq.com writes: >>>On Tue, 20 Dec 2022 20:29:02 +0200 >>>Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>>20.12.2022 17:49 Muttley@dastardlyhq.com kirjutas: >>>>> On Tue, 20 Dec 2022 14:28:31 -0000 (UTC) >>>>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>>> For example, Microsoft's coding guideline says: >>>>> >>>>> I doubt many people would take much notice on MS's opinion on coding. >>>>> >>>>>> "DO NOT use abbreviations or contractions as part of identifier names. >>>>>> For example, use GetWindow rather than GetWin." >>>>> >>>>> Yet oddly at least 3 generations of unix devs have coped with abbreviated >>>>> posix function names such as ioctl(), getuid(), uname() etc without >>>>struggling >>>>> to understand the code. Not to mention standard C functions such as >>fopen(). >>>> >>>>I recall the authors of those names are generally happy with them, >>>>except for one abbreviation: creat(). >>> >>>Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >>>a name people would want to use a lot for their own function names. >> >>IIRC, "creat" actually came from the assembler version of the system call name. > >Still begs the question of why they left off the 'e'. Probably lost in the >mists of time. > https://en.wikiquote.org/wiki/Ken_Thompson Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." https://unix.stackexchange.com/questions/10893/what-did-ken-thompson-mean-when-he-said-id-spell-creat-with-an-e It appears to have been an attempt to save space in source files at a time when disk space was scarce.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-21 16:58 +0000 |
| Message-ID | <tnvdv2$88o$1@gioia.aioe.org> |
| In reply to | #88197 |
On Wed, 21 Dec 2022 16:23:22 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >Muttley@dastardlyhq.com writes: >>Still begs the question of why they left off the 'e'. Probably lost in the >>mists of time. >> > >https://en.wikiquote.org/wiki/Ken_Thompson > > Ken Thompson was once asked what he would do differently if he were > redesigning the UNIX system. His reply: "I'd spell creat with an e." > >https://unix.stackexchange.com/questions/10893/what-did-ken-thompson-mean-when- >he-said-id-spell-creat-with-an-e > >It appears to have been an attempt to save space in source files at a time when > >disk space was scarce. Hmm. That doesn't seem credible even back then. How many times would it be used in any given program? Couldnt have saved more than a few bytes at most. You could achieve far more savings making user functions and variable names shorter.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-21 12:02 -0500 |
| Message-ID | <G_GoL.85641$9sn9.53440@fx17.iad> |
| In reply to | #88199 |
On 12/21/22 11:58 AM, Muttley@dastardlyhq.com wrote: > On Wed, 21 Dec 2022 16:23:22 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: >> Muttley@dastardlyhq.com writes: >>> Still begs the question of why they left off the 'e'. Probably lost in the >>> mists of time. >>> >> >> https://en.wikiquote.org/wiki/Ken_Thompson >> >> Ken Thompson was once asked what he would do differently if he were >> redesigning the UNIX system. His reply: "I'd spell creat with an e." >> >> https://unix.stackexchange.com/questions/10893/what-did-ken-thompson-mean-when- >> he-said-id-spell-creat-with-an-e >> >> It appears to have been an attempt to save space in source files at a time when >> >> disk space was scarce. > > Hmm. That doesn't seem credible even back then. How many times would it be > used in any given program? Couldnt have saved more than a few bytes at most. > You could achieve far more savings making user functions and variable names > shorter. > My memory was that it allowd the storing of a symbol table with entries of 5 6-bit characters in a 32 bit word, with 2 status bits. Making that field larger WOULD significantly increase the size of the symbol tables.
[toc] | [prev] | [next] | [standalone]
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web