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 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-19 05:27 -0800 |
| Message-ID | <f912e031-dd85-49b7-aeef-a11cee31d17dn@googlegroups.com> |
| In reply to | #88028 |
On Monday, 19 December 2022 at 10:39:18 UTC+2, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > Text where recently introduced (within 3-4 code lines) variable
> > with long name participates multiple times feels far from easier
> > to read.
> Are you basing that opinion on code that *you* have written, or are
> you basing it on code by other people that you have had to read?
>
I am writing all less of code than I would like to. Need to give advice,
need to read various ideas, need to review, need to attend meetings.
My improvement proposals have also been lately more about removing
something redundant than about adding new complications. But we
should not contest who has read more hundreds of thousands lines
of code as with decades these add up inevitably.
>
> Because I am basing my opinion on tons and tons of code that I have
> had to read. Clearer variable names (such as loop variable names)
> make a world of a difference in understanding the code.
>
> When I'm writing code, I sometimes find myself instinctively and
> out of old bad habit using eg. loop variable names that are too
> short and too cryptic, and I have been trying to unlearn this bad
> habit and use clearer names. I myself can then see clearly the
> difference that makes when I have to read my own code much later.
>
> This is *especially* the case with nested loops. With some very
> short single loops you could perhaps get away with using
> single-letter index variables. But the longer the loops, and the
> more they are nested, the more important it becomes to name the
> loop variables clearly.
>
Such nested loops themselves have smell of brute force solution
and non-scalable time-complexity. When I see those then I feel obliged
to think deeper as O(I*J*K) is typically THE performance bottle-neck.
When it is unavoidable then order of nesting may matter to cache
friendliness. I actually lack example where verbosity makes it easier
to think about those things.
>
> > What you typically write like "foobar" ... to me just "f" is lot better
> > as "foobar" anyway means nothing.
> Then that name is poorly chosen. It's not about length. It's about
> clarity. The name should clearly express what the thing is for, or
> what it's doing.
>
> Why are people so obsessed with length? For the umpteenth time:
> Length doesn't matter. Length is irrelevant. It's not about making
> names longer or shorter. It's about making them more legible and
> easier to understand. Oftentimes that means making them longer,
> but that's just an irrelevant side-effect, not the core goal.
>
It does not indeed matter at all when I type. IDEs just propose
correct autocompletion after letter or two anyway. But when I read
the long names repeated multiple times in expression feel like
stuttering. DRY! That can be matter of taste, I don't know, you do
not show examples.
>
> Names do not become clearer if they are shorter or longer. They
> become clearer based on their content. Sometimes clearer does mean
> longer, but that's just a side effect.
> > If we anyway see within few previous lines that "i" is index of
> > current image: for(size_t i = 0; i < images.size(); ++i)
> > or "k" is index of current key then names "index_of_current_image"
> > and "index_of_current_key" would not help at all. Opposite has been
> > evident. Demonstrate how it is not.
> I always love it when people give counter-examples by adding
> completely redundant words to the variable names, just for the
> sake of making them longer.
>
I suggested you give examples. Instead you like to critique.
>
> "image_index" is a better name than "index_of_current_image" because
> it doesn't contain redundant information. (The fact that it's also
> shorter is irrelevant. As said, length does not matter.)
>
So your good example is:
for(size_t image_index = 0; image_index < images.size(); ++image_index)
Lot easier than with "i"?
>
> Use as many (full English) words to express what the thing is for,
> but do not add redundant words that add no useful information.
>
> I still fail to undrestand how this is so controversial and worthy of
> such heavy opposition. We are not writing code for the Obfuscated C
> Code Contest here.
>
Simply because I do not see how usage of shorthands causes it to
turn into "Obfuscated C Code Contest".
>
> > It is similar to spoken language where we say "it" or "he"
> There we go again with the length argument. How many times do I have
> to repeat that it's not about the length? A word being shorter or
> longer is completely irrelevant. It's not about the length of the word.
> It's about clarity and legibility.
>
> > in mathematics
>
> Mathematics is an extremely poor example because mathematicians are
> almost proud about the fact that their scribbles are as compressed
> and cryptic as possible.
>
Nope. The problems that mathematicians solve are tricky. Their thought
is lot easier to follow when denoted as they do. Writing same using
full english expressions makes it harder to follow for those who can,
and makes it even more mysterious abracadabra for those who can't.
>
> > Also in legal texts we define shorthands for
> > not to write same thing over and over again.
> As with length, also repetition does not matter. Legibility does. If
> repeating the same word twenty times makes the code more understanable,
> that's all that matters. The repetition itself is irrelevant. We don't
> need to save disk space.
>
It is misrepresentation. I say the expression becomes less concise
and full of stuttering, you say I want to save disk space.
>
> I could add a kind of corollary to my "use as many words as necessary,
> but no more" sentiment: "Repeat the same name in your code as many
> times as necessary, but no more."
>
OK, but what is necessary? For me it is better to read:
auto pI = std::make_unique<Image>(image_file);
or
auto pI = Image::make_ptr(image_file);
Instead of:
std::unique_ptr<Image> image_pointer = std::make_unique<Image>(image_file);
Latter feels like stuttering of "image" ridiculously many times. I feel
like: "I got it, it is image, stop babbling!" when reading it.
>
> >> You use full English words because if you were to contract every
> >> word your text would become illegible. Why is code any different?
> >
> > You are mistaken. Pronouns like it, him, they, there, then are used
> > massively in spoken language.
> They are full words. They are not contractions or acronyms.
>
There are no difference, both cases assume that the reader knows
already what is meant by such pronoun because they did read previous
few lines. If that assumption is incorrect and pronoun can be controversial
then whatever was before was badly formulated. However if it can't be
misunderstood for something else then it helps to comprehend.
>
> > We do exactly same what is done in spoken language, mathematics
> > or legal texts.
> Using mathematics and legal text as examples of "legible" and
> "understandable" text is just hilarious. Legalese is anything but.
>
Good that you noticed! Legalese is anything but understandable
exactly because it tries to be maximally explicit like you seem to
demand, lawyers seem to be paid by text length and so define
shorthands rarely, only to avoid it getting outright comical. Think
about it.
>
> As for spoken language, you don't speak using contractions. You
> speak using full words.
>
If words like "he" or "it" are "full words" or just "shorthands" depends
only on attitude towards those. Between letters and words it is even
more dim. In English there are little to no difference in pronunciation
of "q" and "queue", "t" or "tea", "k" or "key". Nothing to talk of for
example Chinese where every character is "full word" as well. The
whole thing feels like the 40 years ago argument that "begin" is
easier to read than "{". Somehow the proponents of "{" have won.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 15:55 +0000 |
| Message-ID | <tnq1gr$8a3$1@gioia.aioe.org> |
| In reply to | #88042 |
Öö Tiib <ootiib@hot.ee> wrote: > So your good example is: > for(size_t image_index = 0; image_index < images.size(); ++image_index) > Lot easier than with "i"? Easier to read and understand, yes. Absolutely. The longer the loop body, the more it helps. If there are nested loops, it helps even more. (Conversely, the longer the loop body and the more nested loops there are, the more obscure the 'i' becomes, as it gets buried in the code and it's harder to find and remember what it is. Heaven forbid you mix it with 'j'. Now you are just writing obfuscated code.) I don't even understand why this is such a controversial thing. Clearer variable names are better. You will have extremely hard time convincing me otherwise. > OK, but what is necessary? For me it is better to read: > > auto pI = std::make_unique<Image>(image_file); > > or > > auto pI = Image::make_ptr(image_file); > > Instead of: > > std::unique_ptr<Image> image_pointer = std::make_unique<Image>(image_file); > > Latter feels like stuttering of "image" ridiculously many times. I feel > like: "I got it, it is image, stop babbling!" when reading it. I don't see that as a huge problem. Repetition does not reduce clarity. If you want to use 'auto' for iterators, lambdas and unique_ptrs created with make_unique, then fine. The problem is that the "always use auto" people use it with everything, very much in situations where it just hides the type for no good reason and at the expense of clarity. > Good that you noticed! Legalese is anything but understandable > exactly because it tries to be maximally explicit like you seem to > demand, lawyers seem to be paid by text length and so define > shorthands rarely, only to avoid it getting outright comical. Think > about it. No, legalese is not incomprehensible because of the detail, but because of the obfuscated language being used, which is exactly what we want to avoid in code. We want clarity in code, not obfuscation. We don't want obscure terms and acronyms, we want clear full English words that express clearly the meaning.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-20 03:28 -0800 |
| Message-ID | <043c4a79-2f9b-4c37-9383-481dd6f3dbc2n@googlegroups.com> |
| In reply to | #88057 |
On Monday, 19 December 2022 at 17:55:23 UTC+2, Juha Nieminen wrote: > Öö Tiib <oot...@hot.ee> wrote: > > So your good example is: > > for(size_t image_index = 0; image_index < images.size(); ++image_index) > > Lot easier than with "i"? > Easier to read and understand, yes. Absolutely. > > The longer the loop body, the more it helps. If there are nested loops, > it helps even more. (Conversely, the longer the loop body and the > more nested loops there are, the more obscure the 'i' becomes, as it > gets buried in the code and it's harder to find and remember what > it is. Heaven forbid you mix it with 'j'. Now you are just writing > obfuscated code.) > I do not know, for me it is no problem to see that i is indexing images from shorter form just with passing glance. If I somehow forget it during reading next line (how?) then I can look again. > > I don't even understand why this is such a controversial thing. > Clearer variable names are better. You will have extremely hard time > convincing me otherwise. > That seems clear from this discussion. You avoid reading arguments of people and act oddly ... like something of it is sacred ... calm down it is just tool usage. > > > OK, but what is necessary? For me it is better to read: > > > > auto pI = std::make_unique<Image>(image_file); > > > > or > > > > auto pI = Image::make_ptr(image_file); > > > > Instead of: > > > > std::unique_ptr<Image> image_pointer = std::make_unique<Image>(image_file); > > > > Latter feels like stuttering of "image" ridiculously many times. I feel > > like: "I got it, it is image, stop babbling!" when reading it. > I don't see that as a huge problem. Repetition does not reduce clarity. > It is not huge problem. I can get meaning out from far worse text, it just takes bit more time to eyeball it and slight frustration of why they needed to be that boringly repetitive about "image" there. No biggie. > > If you want to use 'auto' for iterators, lambdas and unique_ptrs created > with make_unique, then fine. The problem is that the "always use auto" > people use it with everything, very much in situations where it just > hides the type for no good reason and at the expense of clarity. > I am with you there (like in all written art), brevity may easily be confusing, ambiguous or contradicting. It just is not direct rule that brevity=obfuscation and verbosity=clarity. > > > Good that you noticed! Legalese is anything but understandable > > exactly because it tries to be maximally explicit like you seem to > > demand, lawyers seem to be paid by text length and so define > > shorthands rarely, only to avoid it getting outright comical. Think > > about it. > No, legalese is not incomprehensible because of the detail, but > because of the obfuscated language being used, which is exactly > what we want to avoid in code. We want clarity in code, not > obfuscation. We don't want obscure terms and acronyms, we want > clear full English words that express clearly the meaning. > Haven't observed what you claim. Do you have any example of that "obfuscated language"? That can be so in old jurisdictions without democracy. There spoken language can evolve significantly away from juridical language without need of modernising it so ordinary politicians, members of legislative body understand it. Otherwise majority of the obfuscation of legalese comes from overly big verbosity used in hope to be unambiguous even when shorter formulation would be as unambiguous but have better clarity.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-20 12:09 +0000 |
| Message-ID | <tns8l8$1hck$1@gioia.aioe.org> |
| In reply to | #88121 |
Öö Tiib <ootiib@hot.ee> wrote:
> On Monday, 19 December 2022 at 17:55:23 UTC+2, Juha Nieminen wrote:
>> Öö Tiib <oot...@hot.ee> wrote:
>> > So your good example is:
>> > for(size_t image_index = 0; image_index < images.size(); ++image_index)
>> > Lot easier than with "i"?
>> Easier to read and understand, yes. Absolutely.
>>
>> The longer the loop body, the more it helps. If there are nested loops,
>> it helps even more. (Conversely, the longer the loop body and the
>> more nested loops there are, the more obscure the 'i' becomes, as it
>> gets buried in the code and it's harder to find and remember what
>> it is. Heaven forbid you mix it with 'j'. Now you are just writing
>> obfuscated code.)
>>
> I do not know, for me it is no problem to see that i is indexing images
> from shorter form just with passing glance. If I somehow forget it
> during reading next line (how?) then I can look again.
I'm not sure how I could convey my experience on both reading (huge
amounts of) other people's code and writing my own code and then
reading it months/later, and noticing how much easier it becomes
to read when, for example, loop variables express what they are
indexing or counting.
I understand perfectly that there's this instinct when *writing*
code that using a loop variable name that consists of two full
words feels inconvenient and completely unnecessary. Heck, I myself
still succumb to this from time to time, just because it feels so
much more convenient.
However, when reading code, especially code written by others,
the variable stating what it is for just makes it so much easier
to just read and understand the code. It removes one burden of
having to interpret what a single-letter variable means, from
among a bunch of single-character symbols, because the variable
is directly telling you.
As mentioned elsewhere, the longer the loop body, and the more
nested loops there are, the more important it becomes to name the
loop variables clearly. My rought estimation/rule of thumb is that
this importance grows about linearly with the length of the loop
body, and exponentially with each nested loop.
The worst possible case scenario is having eg. three nested loops,
each using a single-character loop variable, and a significant
amount of code in them. It just clarifies *enormously* if the loop
variables were clearly named. It just does. There is nothing you can
tell me that will convince me to not believe my own eyes.
You can argue that if there are so many nested loops and their bodies
are so long that the loop variables get buried in the code and are
to discern, that's indicative that a refactoring of the entire thing
could be in place. Sure. However, using the clearer loop variable
names doesn't exactly hurt in either case.
There is no reason to use 'i' as a loop variable. There is no advantage.
You can claim all day long that there is some advantage, but I don't
see how I could get convinced of it, when I see with my own eyes the
difference between it and using a variable that actually says what
it's for.
There might be a few situations where using a name like 'i' for a loop
variable (or any variable for that matter) might be warranted, but
they are rare, and even then, I see little disadvantage in using
something clearer. But heaven forbid you use it in a nested loop
with a 'j' as the other loop variable. Now the code becomes genuinely
confusing and obfuscated! I'm not just saying that out of stubborness
or principle. Mixing 'i' and 'j' in the same code, for similar roles,
is really confusing. ('n' and 'm' is not significantly better. 'x'
and 'y' is passable and in some situations it's actually ok, when
we are talking about actual (x, y) cartesian coordinates.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-20 14:45 +0000 |
| Message-ID | <87o7ryuo9u.fsf@bsb.me.uk> |
| In reply to | #88123 |
Juha Nieminen <nospam@thanks.invalid> writes: > Öö Tiib <ootiib@hot.ee> wrote: >> On Monday, 19 December 2022 at 17:55:23 UTC+2, Juha Nieminen wrote: >>> Öö Tiib <oot...@hot.ee> wrote: >>> > So your good example is: >>> > for(size_t image_index = 0; image_index < images.size(); ++image_index) >>> > Lot easier than with "i"? >>> Easier to read and understand, yes. Absolutely. >>> >>> The longer the loop body, the more it helps. If there are nested loops, >>> it helps even more. (Conversely, the longer the loop body and the >>> more nested loops there are, the more obscure the 'i' becomes, as it >>> gets buried in the code and it's harder to find and remember what >>> it is. Heaven forbid you mix it with 'j'. Now you are just writing >>> obfuscated code.) >>> >> I do not know, for me it is no problem to see that i is indexing images >> from shorter form just with passing glance. If I somehow forget it >> during reading next line (how?) then I can look again. > > I'm not sure how I could convey my experience on both reading (huge > amounts of) other people's code and writing my own code and then > reading it months/later, and noticing how much easier it becomes > to read when, for example, loop variables express what they are > indexing or counting. I suspect that part of the trouble is that people "read" code in different ways. From your descriptions it really seems like you do it differently to how I do it. If you think this might be a productive avenue (i.e. you don't think I am just being stubborn) I'd be happy to say more. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-12-28 20:58 -0800 |
| Message-ID | <86y1qqu7p1.fsf@linuxsc.com> |
| In reply to | #88135 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Juha Nieminen <nospam@thanks.invalid> writes: [...] >> I'm not sure how I could convey my experience on both reading (huge >> amounts of) other people's code and writing my own code and then >> reading it months/later, and noticing how much easier it becomes to >> read when, for example, loop variables express what they are >> indexing or counting. > > I suspect that part of the trouble is that people "read" code in > different ways. From your descriptions it really seems like you > do it differently to how I do it. If you think this might be a > productive avenue (i.e. you don't think I am just being stubborn) > I'd be happy to say more. My guess is that reading code in different ways is not just part of the trouble but the crux of the trouble. There is no question that different people read code in different ways, also that the same person reads code in different ways at different times, depending on the circumstances of the reading in question. It seems that Juha doesn't acknowledge these well-established facts.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-29 20:23 +0000 |
| Message-ID | <toksvp$7vv$1@gioia.aioe.org> |
| In reply to | #88288 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > My guess is that reading code in different ways is not just part > of the trouble but the crux of the trouble. There is no question > that different people read code in different ways, also that the > same person reads code in different ways at different times, > depending on the circumstances of the reading in question. It > seems that Juha doesn't acknowledge these well-established facts. Tell me, which is more common, for the average person to understand text written in fully spelled-out words better than text that's littered with obscure acronyms and abbreviations? "I can read the acronyms and abbreviations just fine" doesn't change the fact that the average person doesn't. I don't even understand why this is a discussion. It's a very common thing in coding guidelines out there. What you will *not* find in any coding guideline is something like "avoid using full English words and use acronyms and abbreviations instead" (which is something that at least one person here has asserted as the far superior approach). You are free to prove me wrong.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-20 08:58 -0800 |
| Message-ID | <b92eaedf-7cb3-457d-8d90-4b6a6b30955bn@googlegroups.com> |
| In reply to | #88123 |
On Tuesday, 20 December 2022 at 14:09:31 UTC+2, Juha Nieminen wrote:
>
> I understand perfectly that there's this instinct when *writing*
> code that using a loop variable name that consists of two full
> words feels inconvenient and completely unnecessary. Heck, I myself
> still succumb to this from time to time, just because it feels so
> much more convenient.
>
I already addressed it. No difference in writing convenience about
identifier length. Code editors correctly offer candidates of
autocompletion after typing first letters. You keep repeating
typing difficulty or kilobytes of file or compiler capability to
process it as factor. That could be was considered in seventies.
>
> However, when reading code, especially code written by others,
> the variable stating what it is for just makes it so much easier
> to just read and understand the code. It removes one burden of
> having to interpret what a single-letter variable means, from
> among a bunch of single-character symbols, because the variable
> is directly telling you.
>
If there are lot of single letter variables then it indeed can get rather
cryptic but no one has advocated it.
>
> As mentioned elsewhere, the longer the loop body, and the more
> nested loops there are, the more important it becomes to name the
> loop variables clearly. My rought estimation/rule of thumb is that
> this importance grows about linearly with the length of the loop
> body, and exponentially with each nested loop.
>
I already said that nested loops smell for non-scalable
complexity plus rather formidable bodies mean that it is getting
to grounds of non-testable level of cyclomatic complexity too.
That can't be unfortunately cured with variable naming. I would
be super happy if just more explicit naming would help there. It
just does not.
>
> The worst possible case scenario is having eg. three nested loops,
> each using a single-character loop variable, and a significant
> amount of code in them. It just clarifies *enormously* if the loop
> variables were clearly named. It just does. There is nothing you can
> tell me that will convince me to not believe my own eyes.
>
> You can argue that if there are so many nested loops and their bodies
> are so long that the loop variables get buried in the code and are
> to discern, that's indicative that a refactoring of the entire thing
> could be in place. Sure. However, using the clearer loop variable
> names doesn't exactly hurt in either case.
>
Overly long and comprehensive names indeed hurt far less than the
function itself being so long and complex.
>
> There is no reason to use 'i' as a loop variable. There is no advantage.
> You can claim all day long that there is some advantage, but I don't
> see how I could get convinced of it, when I see with my own eyes the
> difference between it and using a variable that actually says what
> it's for.
>
Overuse of "i" has bothered me too but naming it "index" is even
more pointless than "i", so if it is index of row then "r" is better than
"i" however "row_index" or "row_number" does feel uselessly long,
especially if it appears several times in an expression and is clear
from context.
>
> There might be a few situations where using a name like 'i' for a loop
> variable (or any variable for that matter) might be warranted, but
> they are rare, and even then, I see little disadvantage in using
> something clearer. But heaven forbid you use it in a nested loop
> with a 'j' as the other loop variable. Now the code becomes genuinely
> confusing and obfuscated! I'm not just saying that out of stubborness
> or principle. Mixing 'i' and 'j' in the same code, for similar roles,
> is really confusing. ('n' and 'm' is not significantly better. 'x'
> and 'y' is passable and in some situations it's actually ok, when
> we are talking about actual (x, y) cartesian coordinates.)
>
I still feel that you blame complexity of algorithm itself or whatever
science involved to naming of variables. If function deals with all
of temperatures, times and tickets then naming any of those "t" is
ambiguous. But if it deals with only one of those then it is quite
obvious local shorthand.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-21 06:30 +0000 |
| Message-ID | <tnu96g$sun$1@gioia.aioe.org> |
| In reply to | #88144 |
Öö Tiib <ootiib@hot.ee> wrote:
> Overuse of "i" has bothered me too but naming it "index" is even
> more pointless than "i",
I don't think it's pointless. Sure, it's not the best possible name
because it's not telling *what* it's indexing, just that it's an index
variable... but even that is better than just 'i'. Perhaps not orders
of magnitude better, but still better.
One of the reasons why it's better is that it's more visible in the
code where it's used. You can more easily find it with a quick visual
scan. When reading the code, it's quite literally telling you what
it's doing, and is easier to see where it's doing that.
Of course even better would be if it's telling you more precisely
what it's indexing, because that removes yet another layer of having
to interpret this meaning. If it's a row index, then "row_index" is
significantly better than "index".
> so if it is index of row then "r" is better than
> "i" however "row_index" or "row_number" does feel uselessly long,
> especially if it appears several times in an expression and is clear
> from context.
"r" is not much better than "i" because "r" doesn't tell me anything.
It's just a letter. All by itself it doesn't express what it's
representing. "row_index", however, is *enormously* better than
either because it is directly telling me what it's being used for,
what it represents, and thus it helps reading the code. The fact
that it's longer than a single letter is rather irrelevant. What
matters is how clearly it expresses its meaning. (Although the
length is in a way something that helps a bit because, as mentioned
easlier, it helps seeing where it's being used with a quick visual
scan. However, this is not the most important aspect of it, just
a small additional bonus.)
If there are eg. only two names being used in the loop, then perhaps
the amount of visual help that naming it "row_index" might be less,
because there's less information to read and interpret in the code.
However, the more names and expressions there are, the more it helps
that it's clearly named, and thus more easy to distinguish and
understand from the other names and symbols.
But even if there are just two names being used in the loop code,
it still doesn't hurt to use the clearer variable name, so why not.
I see no problem. We aren't trying to save disk space here.
>> There might be a few situations where using a name like 'i' for a loop
>> variable (or any variable for that matter) might be warranted, but
>> they are rare, and even then, I see little disadvantage in using
>> something clearer. But heaven forbid you use it in a nested loop
>> with a 'j' as the other loop variable. Now the code becomes genuinely
>> confusing and obfuscated! I'm not just saying that out of stubborness
>> or principle. Mixing 'i' and 'j' in the same code, for similar roles,
>> is really confusing. ('n' and 'm' is not significantly better. 'x'
>> and 'y' is passable and in some situations it's actually ok, when
>> we are talking about actual (x, y) cartesian coordinates.)
>>
> I still feel that you blame complexity of algorithm itself or whatever
> science involved to naming of variables. If function deals with all
> of temperatures, times and tickets then naming any of those "t" is
> ambiguous. But if it deals with only one of those then it is quite
> obvious local shorthand.
Not every single piece of code can be written in three simple lines.
code blocks sometimes become long by necessity, and sometimes they
use a lot of identifier names all over the place. If these dozens
of identifier names are all one or two characters, it becomes a
jumbled mess. However, if they are clearly named, telling directly
and easily what they mean, it makes the code so much easier to
read. It does actually help.
I just cannot see the disadvantage of using clearer names. This shouldn't
be a controversial point of view (and is, in fact, a quite commonly
repeated principle eg. in many coding style guidelines).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-20 22:36 -0800 |
| Message-ID | <tnu9i8$v5n2$3@dont-email.me> |
| In reply to | #88171 |
On 12/20/2022 10:30 PM, Juha Nieminen wrote: > Öö Tiib <ootiib@hot.ee> wrote: >> Overuse of "i" has bothered me too but naming it "index" is even >> more pointless than "i", > > I don't think it's pointless. Sure, it's not the best possible name > because it's not telling *what* it's indexing, just that it's an index > variable... but even that is better than just 'i'. Perhaps not orders > of magnitude better, but still better. > > One of the reasons why it's better is that it's more visible in the > code where it's used. You can more easily find it with a quick visual > scan. When reading the code, it's quite literally telling you what > it's doing, and is easier to see where it's doing that. > > Of course even better would be if it's telling you more precisely > what it's indexing, because that removes yet another layer of having > to interpret this meaning. If it's a row index, then "row_index" is > significantly better than "index". > >> so if it is index of row then "r" is better than >> "i" however "row_index" or "row_number" does feel uselessly long, >> especially if it appears several times in an expression and is clear >> from context.[...] I use x, y and z as indices in the loop that builds an n-ary unit grid inside of a unit cube. I posted my personal code for the function that builds it.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-21 08:24 +0000 |
| Message-ID | <tnufr5$1998$1@gioia.aioe.org> |
| In reply to | #88174 |
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> I use x, y and z as indices in the loop that builds an n-ary unit grid
> inside of a unit cube. I posted my personal code for the function that
> builds it.
I tend to use "x", "y" and "z" only if they represent actual cartesian
coordinates (either as integers or floating point). If I'm using them
as some kind of indices to a 2-dimensional (or 3-dimensional) array,
I tend to make it more explicit that they are indices and not really
coordinates (although I admit sometimes, in some cases, the distinction
can be bit artificial.)
But I do make the distinction especially if the code uses both index
variables and cartesian coordinates. Oftentimes this is the case when
dealing with bitmap images, where the pixel coordinates do not
necessarily correspond to the cartesian coordinates. For example:
for(int yIndex = 0; yIndex < image.height(); ++yIndex)
{
double y = (image.height()/2 - yIndex) * scaling_factor;
for(int xIndex = 0; xIndex < image.width(); ++xIndex)
{
double x = (xIndex - image.width()/2) * scaling_factor;
// code that uses (x, y)
// and writes to image[yIndex][xIndex]
}
}
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-01-04 01:49 -0800 |
| Message-ID | <tp3i45$2dmo3$16@dont-email.me> |
| In reply to | #88176 |
On 12/21/2022 12:24 AM, Juha Nieminen wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> I use x, y and z as indices in the loop that builds an n-ary unit grid
>> inside of a unit cube. I posted my personal code for the function that
>> builds it.
>
> I tend to use "x", "y" and "z" only if they represent actual cartesian
> coordinates (either as integers or floating point). If I'm using them
> as some kind of indices to a 2-dimensional (or 3-dimensional) array,
> I tend to make it more explicit that they are indices and not really
> coordinates (although I admit sometimes, in some cases, the distinction
> can be bit artificial.)
>
> But I do make the distinction especially if the code uses both index
> variables and cartesian coordinates. Oftentimes this is the case when
> dealing with bitmap images, where the pixel coordinates do not
> necessarily correspond to the cartesian coordinates. For example:
>
> for(int yIndex = 0; yIndex < image.height(); ++yIndex)
> {
> double y = (image.height()/2 - yIndex) * scaling_factor;
>
> for(int xIndex = 0; xIndex < image.width(); ++xIndex)
> {
> double x = (xIndex - image.width()/2) * scaling_factor;
>
> // code that uses (x, y)
> // and writes to image[yIndex][xIndex]
> }
> }
For me personally, (x, y, z) are easy to understand indices. However, I
can alter my coding to adapt to many different teams requirements and/or
styles. Been there, done that.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2023-01-04 11:07 +0000 |
| Message-ID | <tp3mm2$n7b$1@gioia.aioe.org> |
| In reply to | #88394 |
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> for(int yIndex = 0; yIndex < image.height(); ++yIndex)
>> {
>> double y = (image.height()/2 - yIndex) * scaling_factor;
>>
>> for(int xIndex = 0; xIndex < image.width(); ++xIndex)
>> {
>> double x = (xIndex - image.width()/2) * scaling_factor;
>>
>> // code that uses (x, y)
>> // and writes to image[yIndex][xIndex]
>> }
>> }
>
>
> For me personally, (x, y, z) are easy to understand indices. However, I
> can alter my coding to adapt to many different teams requirements and/or
> styles. Been there, done that.
It depends on the situation. But in situations like the above, where both
indices (that refer to coordinates in some manner) and actual Cartesian
coordinates are both used at the same time, it's quite important to make
the distiction.
Many programmers, when they encounter this clash, might still try to
use names that are as short as possible, such as 'xi' and 'yi', but
I honestly see no advantage over actually spelling out what those
index variables are for, ie. 'xIndex' and 'yIndex' (or 'x_index' and
'y_index', depending on your naming scheme of choice).
Even if you were to argue that 'xi' and 'xIndex' are both equally
understandable, I would still err on the side of actually spelling
it out rather than use an abbreviation. Even if it makes it just
a tiny bit clearer, that's a plus.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-01-04 13:41 -0800 |
| Message-ID | <tp4rqf$2j04f$1@dont-email.me> |
| In reply to | #88397 |
On 1/4/2023 3:07 AM, Juha Nieminen wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> for(int yIndex = 0; yIndex < image.height(); ++yIndex)
>>> {
>>> double y = (image.height()/2 - yIndex) * scaling_factor;
>>>
>>> for(int xIndex = 0; xIndex < image.width(); ++xIndex)
>>> {
>>> double x = (xIndex - image.width()/2) * scaling_factor;
>>>
>>> // code that uses (x, y)
>>> // and writes to image[yIndex][xIndex]
>>> }
>>> }
>>
>>
>> For me personally, (x, y, z) are easy to understand indices. However, I
>> can alter my coding to adapt to many different teams requirements and/or
>> styles. Been there, done that.
>
> It depends on the situation. But in situations like the above, where both
> indices (that refer to coordinates in some manner) and actual Cartesian
> coordinates are both used at the same time, it's quite important to make
> the distiction.
Ahhh. x, y, z are the indices not coordinates. I see where this can
confuse the reader. The code in question is:
___________________________
// GRID!!!!! :^D Okay, let's go...
void
build_field_grid_data(
field_data& fdata,
unsigned long grid_n
) {
// double check
{
/*
// front face
fdata.m_field.push_back({ {-1, -1, 1, 0}, -1, {1, 0, 0, 0} });
fdata.m_field.push_back({ {1, -1, 1, 0}, -1, {0, 1, 0, 0} });
fdata.m_field.push_back({ {1, 1, 1, 0}, -1, {0, 0, 1, 0} } );
fdata.m_field.push_back({ {-1, 1, 1, 0}, -1, {0, 1, 1, 0} });
*/
}
glm::vec3 grid_min = { -1, -1, -1 };
glm::vec3 grid_max = { 1, 1, 1 };
glm::vec3 grid_dif = grid_max - grid_min;
float normal_base = 1.f / grid_n;
unsigned long grid_iter_n = grid_n + 1;
for (unsigned long z = 0; z < grid_iter_n; ++z)
{
for (unsigned long y = 0; y < grid_iter_n; ++y)
{
for (unsigned long x = 0; x < grid_iter_n; ++x)
{
glm::vec3 normal = {
x * normal_base,
y * normal_base,
z * normal_base
};
glm::vec3 p0 = grid_min + grid_dif * normal;
glm::vec4 field_p0 = { p0, 0 };
float field_mass = -1;
fdata.m_field.push_back({ field_p0, field_mass -1, {
normal.x, normal.y, 1 - normal.z, 0} });
}
}
}
fdata.m_field.push_back({ {-3, 0, 0, 0}, 500, {1, 1, 1, 1}});
fdata.m_field.push_back({ {3, 0, 0, 0}, 500, {1, 1, 1, 1} });
}
___________________________
I am creating the normal using the x, y, z indices:
glm::vec3 normal = {
x * normal_base,
y * normal_base,
z * normal_base
};
> Many programmers, when they encounter this clash, might still try to
> use names that are as short as possible, such as 'xi' and 'yi', but
> I honestly see no advantage over actually spelling out what those
> index variables are for, ie. 'xIndex' and 'yIndex' (or 'x_index' and
> 'y_index', depending on your naming scheme of choice).
>
> Even if you were to argue that 'xi' and 'xIndex' are both equally
> understandable, I would still err on the side of actually spelling
> it out rather than use an abbreviation. Even if it makes it just
> a tiny bit clearer, that's a plus.
What about x_index ? I don't mind using underscores. I have did enough
work with pthread's where an underscore is no problem at all.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-21 15:38 +0000 |
| Message-ID | <1MFoL.17267$rKDc.12199@fx34.iad> |
| In reply to | #88171 |
Juha Nieminen <nospam@thanks.invalid> writes:
>Öö Tiib <ootiib@hot.ee> wrote:
>> Overuse of "i" has bothered me too but naming it "index" is even
>> more pointless than "i",
>
>I don't think it's pointless. Sure, it's not the best possible name
>because it's not telling *what* it's indexing, just that it's an index
>variable... but even that is better than just 'i'. Perhaps not orders
>of magnitude better, but still better.
So, how about this?
unsigned char *bp = (unsigned char *)d_mp->get_ioaddr(bufaddr);
ulong remaining = bufsize;
unsigned char *ap;
...
ap = u_write_buffer = (unsigned char *)malloc(bufsize);
if (ap == NULL) {
unlock();
d_logger->log("%s Unable to allocate %lu bytes: %s\n",
u_dlp_name, bufsize, strerror(errno));
set_rd(iocb, IOT_WITH_EXCEPTIONS, RD_NOT_READY);
return false;
}
for (;remaining > 0; bp++) {
if (iocb->ascii_xlate()) {
*ap++ = c_ebcdic::to_ascii(*bp);
} else {
*ap++ = *bp;
}
remaining--;
if (is_control(*bp)) break;
}
Readable? Unreadable?
Anyone working on the code would know implicitly that
"rd" is an abbreviation for Result Descriptor; anyone
who doesn't know that shouldn't be mucking about in the
code in the first place.
Context is important.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-22 12:32 +0000 |
| Message-ID | <to1io1$hpk$1@gioia.aioe.org> |
| In reply to | #88193 |
Scott Lurndal <scott@slp53.sl.home> wrote: > So, how about this? > > unsigned char *bp = (unsigned char *)d_mp->get_ioaddr(bufaddr); > ulong remaining = bufsize; > unsigned char *ap; > > ... > > ap = u_write_buffer = (unsigned char *)malloc(bufsize); I think this is a quite good example where using acronyms and abbreviations is detrimental to readability and undrestandability. It's not clear at all what "d_mp" even stands for, much less what it means. "get_ioaddr" is relatively clear, but I don't really see a reason to abbreviate it (but it's by far not the worst offender in this code). Same could be said of "bufaddr" and "bufsize". (If "bufaddr" and "bufsize" are not just completely generic variables/constants to be used in any sort of buffer allocation and management, then they could be named generically like that (although I would still prefer if they were not abbreviated). However, if their intent is to determine the characteristics of a *particular type* of buffer, or even a *particular buffer*, it would be clearer if they said that, so that they couldn't be confused with some other buffers that might be used in the program.) The name "bp" is unnecessarily obscure. Is it "buffer pointer" perhaps? I see no reason why it couldn't just say that outright, if that's what it means. Why have the reader guess? There's no reason. "remaining" is a full English word, yay! But yet, it doesn't really say remaining what, exactly. IMO it could say what it's counting, not just that it's counting a remaining amount of *something*. It's not clear at all what "ap" means. Something pointer, I suppose, but what? Why couldn't it just say it? It would be so much easier to understand, without having to guess. > anyone > who doesn't know that shouldn't be mucking about in the > code in the first place. Is this some kind of elitism in programming?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-22 16:20 +0000 |
| Message-ID | <6t%oL.17379$rKDc.862@fx34.iad> |
| In reply to | #88219 |
Juha Nieminen <nospam@thanks.invalid> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> anyone
>> who doesn't know that shouldn't be mucking about in the
>> code in the first place.
>
>Is this some kind of elitism in programming?
No, it means that one should know the problem space before
modifying a program in that space.
This program is an full-system emulator for a mainframe
computer system. Which has a memory subsystem (mp),
so the 'mp' abbreviation, like the 'rd' (result descriptor)
abbreviation is understandable to someone familiar
with the problem space.
I'm not going to type memory_pointer instead
of mp. (the d_ prefix has meaning[*] within the context of the
application, granted it's not clear from a 15 line snippet).
[*] in this case, it visually identifies the identifier as
a class member for the base (c_dlp) class.
(And someone familiar with the problem space would instantly
recognized DLP as an abbreviation for Data Link Processor
which is a term of art in that problem space along with
IOCB for I/O control block).
/**
* Base class defining a Data Link Processor (DLP).
*/
class c_dlp: public c_thread {
...
c_logger *d_logger;
c_memory *d_mp;
c_processor *d_processor;
pthread_cond_t d_wait;
c_dlist d_iocbs; // IOCB's pending execution
bool d_busy; // pre-Revision B busy flag
volatile bool d_exit; // Thread exit flag
volatile bool d_exited; // Thread exit done flag
ulong d_testid; // DLP Type code
ulong d_channel; // channel for this DLP instance
...
/**
* Uniline DLP.
*
* A Uniline DLP is a three-card DLP containing a microprocessor and
* a universal synchronous/asynchronous receiver/transmitter. Firmware
* is downloaded to the DLP to provide line discipline code for managing
* point-to-point and multidrop RS-232C and Burroughs Two-Wire Direct (TDI)
* Interface block-mode display devices.
*
* Two firmware versions are available for the Uniline dlp:
* USP3BV - Operator Control Station (OCS) firmware. Supports
* a single contention mode station.
* UST3BH - Supports a multidrop configuration of one or more
* stations using the Burroughs Poll-Select
* protocol.
*
* When OCS firmware (USP3BV) is loaded, the dlp mode is set to
* U_OCS. A subsequent 'control cc/u netport' command should
* be issued to establish a network listener for the operator control
* station.
*
* When STC (Standard Terminal Control) firmware (UST3BH) is loaded,
* the dlp mode will be set to U_STC and a network listener will provide
* access to a remote terminal or remote job entry client.
*/
class c_uniline_dlp : public c_dlp,
c_timer_callable,
c_port_transport,
c_port_listener {
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-22 17:04 +0000 |
| Message-ID | <to22mv$7pa$1@gioia.aioe.org> |
| In reply to | #88222 |
Scott Lurndal <scott@slp53.sl.home> wrote: > I'm not going to type memory_pointer instead of mp The question is: Why not? I'm asking seriously. This is not just arguing for the sake of arguing. What exactly is the problem in writing the full version instead of the acronym? I don't think lines of code become "too long" because of that (and if they do, perhaps you should consider if you are cramming too much into one single line of code...) It does not decrease readability. (Seriously, it does not, completely objectively speaking. I know certain individual(s) here claim otherwise, but that's just not an objective fact.) So why not? Writing it out helps the person reading the code remind himself what it means, and makes it much clearer in every instance where it's used.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-13 06:43 -0800 |
| Message-ID | <91e106d6-4b61-470c-a690-8f826eeb505bn@googlegroups.com> |
| In reply to | #87858 |
On Tuesday, December 13, 2022 at 3:42:32 AM UTC-5, David Brown wrote: > > > short code can be easy to understand - easier than long versions. > Sometimes it is simply the fact that the code is shorter that makes it > easier to understand - people generally write "long" instead of "signed > long int" precisely because it is shorter and requires less cognitive > effort to understand. > > "auto", used appropriately, can do the same thing. auto can be convenient, very convenient for auto iter = vec.begin(); But it can also be wrong, when auto value = copy of proxy I don't know of another language where var value = foo() is correct in some contexts and wrong in others. Surely some cognitive effort required there. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Udo Steinbach <trashcan@udoline.de> |
|---|---|
| Date | 2022-12-14 18:43 +0100 |
| Message-ID | <tnd204$2rbe2$1@dont-email.me> |
| In reply to | #87858 |
Am 2022-12-13 um 09:42 schrieb David Brown:
> calculate_average_of_vector_of_ints() {
> int the_size_of_the_vector_of_ints_to_average
I love practical examples used to support the opposite practical point of view.
> Are you seriously suggesting that the first version is "clearer"
Cheap straw man.
int CalcAverage(std::vector<int> Throughput) {
{ int Sum= 0;
for (int Current : Throughput)
Sum += Current;
return Sum / Throughput.size();
}
--
Fahrradverkehr in Deutschland: http://radwege.udoline.de/
GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E
[toc] | [prev] | [next] | [standalone]
Page 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web