Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #175828 > unrolled thread
| Started by | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| First post | 2023-09-18 01:21 +0300 |
| Last post | 2023-09-18 07:21 -0700 |
| Articles | 20 on this page of 195 — 17 participants |
Back to article view | Back to comp.lang.c
Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-18 01:21 +0300
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-18 01:23 +0300
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 00:32 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-09-18 10:55 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 13:40 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-18 06:02 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 17:10 +0200
Re: Do you insist on const-correctness? "comp.lang.c" <malcolm.arthur.mclean@gmail.com> - 2023-09-18 16:47 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 09:25 +0200
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-19 02:57 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:31 -0700
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-19 03:54 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 16:54 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:33 -0700
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-19 14:56 -0700
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-19 13:43 +0000
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 12:49 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 19:10 +0300
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-17 17:17 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-09-18 11:53 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 16:55 +0200
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-18 15:54 +0000
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 18:10 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-18 19:36 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 19:55 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-18 21:57 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 14:00 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 21:26 +0000
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 15:55 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 09:33 +0200
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 21:59 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-18 22:01 +0100
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 22:16 +0100
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 15:51 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 22:59 +0000
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 16:04 -0700
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 16:19 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 16:24 -0700
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 16:44 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 17:37 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 09:41 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-19 10:12 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 17:10 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-19 22:22 +0100
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-19 15:35 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 22:44 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-20 12:55 +0200
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 14:07 -0700
Re: Do you insist on const-correctness? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-19 00:13 -0400
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-19 09:57 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 16:37 +0200
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 16:55 +0000
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 15:16 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 20:31 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 14:03 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 14:04 -0700
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 22:26 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 15:59 -0700
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-19 00:37 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:26 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 17:15 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 11:00 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 17:01 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-23 16:35 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 19:13 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 10:38 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 19:05 +0300
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-23 18:45 +0100
Re: Do you insist on const-correctness? Richard Damon <Richard@Damon-Family.org> - 2023-09-23 14:24 -0400
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-24 17:05 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-24 23:26 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 08:43 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 11:51 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 15:40 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 18:56 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 11:03 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 19:53 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 11:55 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 20:08 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 21:29 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 12:42 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 21:11 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-26 08:55 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 00:22 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 15:03 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 14:37 +0300
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 14:57 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-26 17:21 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 13:49 +0100
Re: Do you insist on const-correctness? cross@spitfire.i.gajendra.net (Dan Cross) - 2023-09-26 13:57 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 17:14 +0300
Re: Do you insist on const-correctness? cross@spitfire.i.gajendra.net (Dan Cross) - 2023-09-26 14:27 +0000
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-26 15:22 +0000
Re: Do you insist on const-correctness? cross@spitfire.i.gajendra.net (Dan Cross) - 2023-09-26 17:45 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-26 17:10 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-26 08:29 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:04 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 03:37 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 17:03 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 08:35 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 18:52 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 10:46 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 20:26 +0200
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-27 11:45 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 21:19 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:34 -0700
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 01:11 +0100
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 19:32 +0100
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 17:12 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-28 01:49 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 17:53 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-28 11:21 +0100
Re: Do you insist on const-correctness? Psychedelics Haven <psychedelicshaven@gmail.com> - 2023-09-28 04:01 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:56 +0300
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 07:15 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 18:38 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-28 21:47 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 01:45 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-29 10:38 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 14:33 +0300
Re: Do you insist on const-correctness? Spiros Bousbouras <spibou@gmail.com> - 2023-09-29 12:10 +0000
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-29 05:28 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-29 15:19 +0100
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-29 15:18 +0100
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 02:18 -0700
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 18:04 -0700
[OT] missing evidence (Was: Do you insist on const-correctness?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 02:31 +0100
Re: [OT] missing evidence (Was: Do you insist on const-correctness?) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 21:02 -0700
Re: [OT] missing evidence (Was: Do you insist on const-correctness?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 21:48 -0700
Re: [OT] missing evidence (Was: Do you insist on const-correctness?) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 22:33 -0700
Re: [OT] missing evidence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 16:52 +0100
Re: [OT] missing evidence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-29 18:19 -0700
Re: [OT] missing evidence Anton Shepelev <anton.txt@gmail.moc> - 2023-09-30 13:06 +0300
Re: [OT] missing evidence David Brown <david.brown@hesbynett.no> - 2023-09-30 17:30 +0200
Re: [OT] missing evidence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 00:33 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 17:13 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 00:50 +0300
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 14:19 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 14:21 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:29 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:32 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-28 21:24 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 23:05 +0300
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 14:18 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 16:57 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 16:40 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 18:46 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:37 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 15:13 +0300
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 13:32 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 19:00 +0200
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 01:34 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-28 10:08 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-28 10:37 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-28 14:13 +0200
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 13:50 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:37 +0300
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 14:46 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:23 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 11:42 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 15:27 +0300
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 06:44 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 17:56 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-27 22:12 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 23:53 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:25 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 17:00 +0000
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 09:58 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 00:41 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 22:33 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 01:50 +0300
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 09:56 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 17:42 +0000
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 15:42 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:19 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 20:53 +0300
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 19:15 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 23:05 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 01:45 +0100
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-26 19:43 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-27 03:21 +0000
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-26 20:56 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 10:36 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-27 03:17 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 16:46 +0200
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 21:16 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 00:38 +0300
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-29 10:07 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-30 17:34 +0200
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-23 11:57 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-24 00:07 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 02:38 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-09-18 11:07 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 15:24 +0000
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-18 07:21 -0700
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-25 12:42 -0700 |
| Message-ID | <uesnro$22s1l$1@dont-email.me> |
| In reply to | #176385 |
On 9/25/2023 12:29 PM, David Brown wrote: > On 25/09/2023 20:53, Bart wrote: >> On 25/09/2023 19:03, Chris M. Thomasson wrote: >>> On 9/25/2023 10:56 AM, Bart wrote: >>>> On 25/09/2023 14:40, David Brown wrote: >>>>> On 25/09/2023 12:51, Bart wrote: >>>> >>>>>> suppose I define a typedef say at module scope to be shared by >>>>>> functions 35, 62 and 78 of 100 functions in that module. >>>>>> >>>>>> Where should I place that typedef: before the definition of >>>>>> function 1, or immediately before function 35 since that is where >>>>>> it is first used? >>>>>> >>>>> >>>>> That's a stupid question. Don't have 100 functions in your module. >>>> >>>> Huh? I didn't realise that was that controversial. I don't actually >>>> know how many functions I have per module, I've never counted! >>> >>> I think there is a complexity rule is MISRA that talks about this... >> > > I am pretty sure there is no such rule. I can't see it in my copy of > MISRA C 2012 (though I don't claim to be very familiar with the > document, so I might have missed something). > >> Are there are also rules about how many lines in a function, and how >> many modules in a program? > > There is the concept of "Cyclomatic complexity" > (<https://en.wikipedia.org/wiki/Cyclomatic_complexity>) which suggests > that overly complex functions become impossible to test or even to fully > comprehend. > >> >> Minimising one will increase the number of functions, and minimising >> the number of functions per module will increase the number of modules. >> > > There can certainly be tradeoffs, yes. Sometimes splitting things up > gives better refactorisation and more code reuse, reducing the overall > size. But the idea is to deal with manageable chunks at each level. If > you are having trouble finding information you need, you have probably > chosen the splits poorly - that could mean you have too many divisions, > or divisions in the wrong places, as well as possibly meaning your parts > are too big. It could also mean that you are looking for too much > detail at an inappropriate level - maybe knowing all the details of a > type or a function isn't actually important in order to use it correctly. > >> Further, there will be more complexity due to interactions or >> interfaces between functions and between modules being exposed, that >> could have been kept private. > > That can indeed be a factor. That is one of the reasons why I can't > give any fixed answers. > > But if you tell me you have 100 functions in a module, with use of an > important type scattered randomly amongst them, and it's hard to know > where to put the type definition - then my first guess is the module is > too big. I might change that opinion when I know details of it and why > the code structure is this way, but that's my initial reaction. > > > I must of remembered it wrong David. I think I remember something about trying not to have too many functions in a class...
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-25 21:11 +0000 |
| Message-ID | <20230925140653.578@kylheku.com> |
| In reply to | #176386 |
On 2023-09-25, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > I must of remembered it wrong David. I think I remember something about > trying not to have too many functions in a class... If you have 100 functions in a module, such that a typical use of the module has to use 95 of them, that's probably not very good. (Even then, if there is a good argument that there is no other way it can be done, while meeting some non-negotiable requirement, then it is what it is.) If they are various utilities that benefit certain usage scenarios of the module, it may be acceptable to have a plethora of them. Then we are just worried about code size in small systems: do we have a linker that will remove individual unused function, or only unused object files. There is a case for having a detailed configuration system whereby the integrator can select which functions are going to be present in the image. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-26 08:55 +0200 |
| Message-ID | <uetv8m$2cqip$1@dont-email.me> |
| In reply to | #176386 |
On 25/09/2023 21:42, Chris M. Thomasson wrote: > > I must of remembered it wrong David. I think I remember something about > trying not to have too many functions in a class... That is not in MISRA either, nor in the JSF rules you linked. (The JSF rules take a lot of inspiration from MISRA, and are IMHO a better set of rules.) I don't know of any coding standards that have fixed maximum limits to the size of functions or the number of functions in a file. That makes sense, since there is no way to pick an absolute limit - it varies too much by circumstance. The best you can have is a generalisation, not a rule - do not make your source files so big or have so many functions that they are difficult to navigate.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-26 00:22 -0700 |
| Message-ID | <ueu0sh$2d5c9$1@dont-email.me> |
| In reply to | #176419 |
On 9/25/2023 11:55 PM, David Brown wrote: > On 25/09/2023 21:42, Chris M. Thomasson wrote: >> >> I must of remembered it wrong David. I think I remember something >> about trying not to have too many functions in a class... > > That is not in MISRA either, nor in the JSF rules you linked. (The JSF > rules take a lot of inspiration from MISRA, and are IMHO a better set of > rules.) > > I don't know of any coding standards that have fixed maximum limits to > the size of functions or the number of functions in a file. That makes > sense, since there is no way to pick an absolute limit - it varies too > much by circumstance. The best you can have is a generalisation, not a > rule - do not make your source files so big or have so many functions > that they are difficult to navigate. > > Yeah. I was misremembering section 3.2: ________________________________ 3.2 Code Size and Complexity AV Rule 1 Any one function (or method) will contain no more than 200 logical source lines of code (LSLOCs). Rationale: Long functions tend to be complex and therefore difficult to comprehend and test. Note: Section 4.2.1 defines should and shall rules as well the conditions under which deviations from should or shall rules are allowed. AV Rule 2 There shall not be any self-modifying code. Rationale: Self-modifying code is error-prone as well as difficult to read, test, and maintain. AV Rule 3 All functions shall have a cyclomatic complexity number of 20 or less. Rationale: Limit function complexity. See AV Rule 3 in Appendix A for additional details. Exception: A function containing a switch statement with many case labels may exceed this limit. Note: Section 4.2.1 defines should and shall rules as well the conditions under which deviations from should or shall rules are allowed. ________________________________ And appendix A wrt AV rule 3.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-26 15:03 -0700 |
| Message-ID | <uevkg9$2mqsq$1@dont-email.me> |
| In reply to | #176423 |
On 9/26/2023 12:22 AM, Chris M. Thomasson wrote: > On 9/25/2023 11:55 PM, David Brown wrote: >> On 25/09/2023 21:42, Chris M. Thomasson wrote: >>> >>> I must of remembered it wrong David. I think I remember something >>> about trying not to have too many functions in a class... >> >> That is not in MISRA either, nor in the JSF rules you linked. (The >> JSF rules take a lot of inspiration from MISRA, and are IMHO a better >> set of rules.) >> >> I don't know of any coding standards that have fixed maximum limits to >> the size of functions or the number of functions in a file. That >> makes sense, since there is no way to pick an absolute limit - it >> varies too much by circumstance. The best you can have is a >> generalisation, not a rule - do not make your source files so big or >> have so many functions that they are difficult to navigate. >> >> > > Yeah. I was misremembering section 3.2: > ________________________________ > 3.2 Code Size and Complexity > AV Rule 1 > Any one function (or method) will contain no more than 200 logical > source lines of code (LSLOCs). > Rationale: Long functions tend to be complex and therefore difficult to > comprehend and test. For some reason the rationale reminded me of you and Kaz wrt being a good programmer. :^) > Note: Section 4.2.1 defines should and shall rules as well the > conditions under which > deviations from should or shall rules are allowed. > AV Rule 2 > There shall not be any self-modifying code. > Rationale: Self-modifying code is error-prone as well as difficult to > read, test, and maintain. > AV Rule 3 > All functions shall have a cyclomatic complexity number of 20 or less. > Rationale: Limit function complexity. See AV Rule 3 in Appendix A for > additional details. > Exception: A function containing a switch statement with many case > labels may exceed this > limit. > Note: Section 4.2.1 defines should and shall rules as well the > conditions under which > deviations from should or shall rules are allowed. > ________________________________ > > And appendix A wrt AV rule 3.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-26 14:37 +0300 |
| Message-ID | <20230926143726.8fd502c51264c4e127203da4@gmail.moc> |
| In reply to | #176379 |
Bart:
> Chris M. Thomasson:
> > Bart:
> >
> > > Huh? I didn't realise that was that controversial. I
> > > don't actually know how many functions I have per
> > > module, I've never counted!
> >
> > I think there is a complexity rule is MISRA that talks
> > about this...
>
> Are there are also rules about how many lines in a
> function, and how many modules in a program?
In fact, there are. There strictest ones I have ever met
with belong to Rebert Martin. In /Clean code/, he proposes
that a function have no more than 20 lines (and at most 3
parameters!), and a module no more than 200 lines.
Programmers tend to put limits on the complexity of the
lower-level (tactical?) program elements with which they
work, at the expense of higher-level (strategical?)
complexity describing modules/classes/interfaces.
In a 20-line function, I prefer the local variables declared
at the beginning, whereas in a 100-line function they are a
nuisance, but then there are likely other problems with the
function as well, such as trying to do too much, or
embracing more than one level of the conceptual task
hierarchy.
No, I cannot follow Martin's rules even for 80% of my code,
for various reasons. I cannot have a maximum of three
parameters without introducing ad-hoc stuctures to group
them /specificaly/ for that one call. Futhermore, if a
function returns an error flag, providing error details
(text, code, or perhaps a stack of text and code records) in
an output parameter, I am left with but one input parameter
and one output parameter (because the return value is in
use) -- clearly not enough. But that rules is possible in
popular OOP, because classes provide a /lot/ of additional
context to functions (one huge /self/ parameter), and errors
are frequently signalled out-or-bandwith, i.e. via
exceptions (no explicit error code and error info).
Modern languages with multiple returns or tuples provide a
partial solution, another being to unify error info with the
result of successful execution in dynamic languages or ones
with templates (to save the declaring a combined TResult
type for every function). But then, I loose the whole
pupose of an error flag -- the ability to invoke funtions
inside an `if' statement.
> Further, there will be more complexity due to interactions
> or interfaces between functions and between modules being
> exposed, that could have been kept private.
I believe that with a good architecture this kind of higher-
level, strategical complexity is easier to manage, where I
agree with the mainstream consensus. The essence is exactly
to escalate tatcical low-level devilish complexity into the
cloulds, and there to deal with it with more elbow-room.
There are many measures of code/program/architecture
complexity. I wonder if anybody has tried to link with the
depth of nesting directly, although not via the primitive
max or mean statistics, but via something smarter, such as
median, or weighted average.
Linus 8-chareater-tab Torvalds was IMHO right when he
decreed that a function shall not have more then three
levels of nesting, his enourmous tab serving as a dumb,
primitive, mechanical, and ugly means of enforsing this
decree.
I observe that technological progress provides a basis for a
sort of programming nazism, where all code is
unconditionally and obligatorily processed throught a
pretty- (aka ugly-) -printer before even a review, so that
the programmer cannot use any formatting whatsoever to
emphasize structure or better express his intent.
For an example, and the standard if-else-if-else... chain is
in fact a variant of a switch, and a switch has the
structure of a flat, two-dimensional table. That said, the
deeply nested format, often assumed for granted, is wrong (I
hope everyone reads this group in monospace font):
if( test_1 ) {
stat_1 } else {
if( test_2 ) {
stat_2 } else {
if( test_3 ) {
stat_3 } else {
and the correct format is flat and table-like:
if( test_1 ) stat_1;
else if( test_2 ) stat_2;
else if( test_3 ) stat_3;
It shorter, clearer, and better structured, because the
programmer has formatted the code according its intent.
Observe also the indent of the first `if' to have it aligned
with the other entries of the table.
Coding standard rarery (if ever) take these semantical
(intent) and perceptinve (table) considerations into accout,
whereas automatic linters or pretty-printers supply the
necessary technology to implement this Nazism.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-26 14:57 +0300 |
| Message-ID | <20230926145757.995e547e064b8fe0347c079c@gmail.moc> |
| In reply to | #176436 |
I wrote:
> For an example, and the standard if-else-if-else... chain
> is in fact a variant of a switch, and a switch has the
> structure of a flat, two-dimensional table. That said,
> the deeply nested format, often assumed for granted, is
> wrong (I hope everyone reads this group in monospace
> font):
>
> if( test_1 ) {
> stat_1 } else {
> if( test_2 ) {
> stat_2 } else {
> if( test_3 ) {
> stat_3 } else {
>
> and the correct format is flat and table-like:
>
> if( test_1 ) stat_1;
> else if( test_2 ) stat_2;
> else if( test_3 ) stat_3;
>
> It shorter, clearer, and better structured, because the
> programmer has formatted the code according its intent.
> Observe also the indent of the first `if' to have it
> aligned with the other entries of the table.
>
> Coding standard rarely (if ever) take these semantical
> (intent) and perceptinve (table) considerations into
> accout, whereas automatic linters or pretty-printers
> supply the necessary technology to implement this Nazism.
By the way, my restructuring in the latter format of a large
if-else- chain in DOSBox Staging did not pass code reivew,
the maintainer demanding that I revert it to the "correct"
form it had, which reminds me of another thought: that
enforced coding standards, especially in large projects with
a large and volatile body of programmers, serve to utilise
and organise the effort of so many sheep, who are a not
allowed to think for themselves, nor express themselves.
Junior programmers, fresh for the their university (or
whatever institution), find themselves thus shackled by
their first employer, and indoctrinated into mainstream
dogma at unawares, without a chance at reflection, thereby
losing the ability or independent judjement.
Thus, I know programmers who never gave thought to their
coding style. They simply process their code with the
standard formatting tool (with default settigns!) for their
language and don't care of the rest. This is encouraged, to
facilitate entry into the Nazi party: everbody else is doing
it, employees require it.
To avoid a grave misunderstanding -- the above does not
apply to anybody who has arrived at the mainstream consensus
by way of reason, rather than indoctrination.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-26 17:21 +0200 |
| Message-ID | <ueusu7$2if5b$1@dont-email.me> |
| In reply to | #176437 |
On 26/09/2023 13:57, Anton Shepelev wrote:
> I wrote:
>
>> For an example, and the standard if-else-if-else... chain
>> is in fact a variant of a switch, and a switch has the
>> structure of a flat, two-dimensional table. That said,
>> the deeply nested format, often assumed for granted, is
>> wrong (I hope everyone reads this group in monospace
>> font):
>>
>> if( test_1 ) {
>> stat_1 } else {
>> if( test_2 ) {
>> stat_2 } else {
>> if( test_3 ) {
>> stat_3 } else {
>>
>> and the correct format is flat and table-like:
>>
>> if( test_1 ) stat_1;
>> else if( test_2 ) stat_2;
>> else if( test_3 ) stat_3;
>>
>> It shorter, clearer, and better structured, because the
>> programmer has formatted the code according its intent.
>> Observe also the indent of the first `if' to have it
>> aligned with the other entries of the table.
>>
>> Coding standard rarely (if ever) take these semantical
>> (intent) and perceptinve (table) considerations into
>> accout, whereas automatic linters or pretty-printers
>> supply the necessary technology to implement this Nazism.
>
> By the way, my restructuring in the latter format of a large
> if-else- chain in DOSBox Staging did not pass code reivew,
> the maintainer demanding that I revert it to the "correct"
> form it had, which reminds me of another thought: that
> enforced coding standards, especially in large projects with
> a large and volatile body of programmers, serve to utilise
> and organise the effort of so many sheep, who are a not
> allowed to think for themselves, nor express themselves.
Sorry, but you are wrong here.
Consistent style is very important in large projects, greatly reducing
the effort needed for different programmers to understand and work on
different bits of code. Consistency is usually more important than the
details of the style. Maverick styles like yours have no place in group
efforts.
> Junior programmers, fresh for the their university (or
> whatever institution), find themselves thus shackled by
> their first employer, and indoctrinated into mainstream
> dogma at unawares, without a chance at reflection, thereby
> losing the ability or independent judjement.
>
You are the one who is using a style that, at best, might have been of
interest decades ago. Perhaps you were not influenced by mainstream
coding styles, but that's nothing to be proud of - other people know
better than you, but you have not learned from them. Looking at other
styles and taking the best from them (where "best" depends on many
factors, and is not absolute) is not "indoctrination", it is just
learning from other people's experiences.
> Thus, I know programmers who never gave thought to their
> coding style. They simply process their code with the
> standard formatting tool (with default settigns!) for their
> language and don't care of the rest. This is encouraged, to
> facilitate entry into the Nazi party: everbody else is doing
> it, employees require it.
>
If you don't have particular reason to pick a different style, then
common standards are usually a very good starting point. Maybe the
programmer using them hasn't thought them through in detail - but
/someone/ has.
You /have/ thought about your coding style. That does not make it good.
You just think it is good because you have used it for decades.
> To avoid a grave misunderstanding -- the above does not
> apply to anybody who has arrived at the mainstream consensus
> by way of reason, rather than indoctrination.
>
Some people have this bizarre notion that following common standards, or
listening to mainstream opinions, or - heaven forbid! - paying attention
to established and qualified experts is somehow "indoctrination". Did
it ever occur to you that sometimes when lots of people agree on
something, or work the same way, it is perhaps because it is a good idea?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-26 13:49 +0100 |
| Message-ID | <ueuk1n$2gm39$1@dont-email.me> |
| In reply to | #176436 |
On 26/09/2023 12:37, Anton Shepelev wrote:
> Bart:
>> Chris M. Thomasson:
>>> Bart:
>>>
>>>> Huh? I didn't realise that was that controversial. I
>>>> don't actually know how many functions I have per
>>>> module, I've never counted!
>>>
>>> I think there is a complexity rule is MISRA that talks
>>> about this...
>>
>> Are there are also rules about how many lines in a
>> function, and how many modules in a program?
>
> In fact, there are. There strictest ones I have ever met
> with belong to Rebert Martin. In /Clean code/, he proposes
> that a function have no more than 20 lines (and at most 3
> parameters!), and a module no more than 200 lines.
> Programmers tend to put limits on the complexity of the
> lower-level (tactical?) program elements with which they
> work, at the expense of higher-level (strategical?)
> complexity describing modules/classes/interfaces.
>
> In a 20-line function, I prefer the local variables declared
> at the beginning, whereas in a 100-line function they are a
> nuisance, but then there are likely other problems with the
> function as well, such as trying to do too much, or
> embracing more than one level of the conceptual task
> hierarchy.
>
> No, I cannot follow Martin's rules even for 80% of my code,
> for various reasons. I cannot have a maximum of three
> parameters without introducing ad-hoc stuctures to group
> them /specificaly/ for that one call. Futhermore, if a
> function returns an error flag, providing error details
> (text, code, or perhaps a stack of text and code records) in
> an output parameter, I am left with but one input parameter
> and one output parameter (because the return value is in
> use) -- clearly not enough. But that rules is possible in
> popular OOP, because classes provide a /lot/ of additional
> context to functions (one huge /self/ parameter), and errors
> are frequently signalled out-or-bandwith, i.e. via
> exceptions (no explicit error code and error info).
>
> Modern languages with multiple returns or tuples provide a
> partial solution,
To some arbitrarily limit? That would defeat the purpose of the rule:
you can't have more than 3 arguments, but any of those 3 can be a tuple
with 28 arguments!
Presumably that made-up rule was invented before named argument lists
came about. Then, functions with lots of parameters that have default
values, don't need to be called with all the arguments.
(Is there another equally silly rule about not having more than 3
members in a struct?)
>> Further, there will be more complexity due to interactions
>> or interfaces between functions and between modules being
>> exposed, that could have been kept private.
>
> I believe that with a good architecture this kind of higher-
> level, strategical complexity is easier to manage, where I
> agree with the mainstream consensus. The essence is exactly
> to escalate tatcical low-level devilish complexity into the
> cloulds, and there to deal with it with more elbow-room.
>
> There are many measures of code/program/architecture
> complexity.
C gives ample opporunity for complexity in what is supposed to be a
simple language:
* Burying things in layers of macros
* Having nested, conditional code blocks
So that is impossible to see, just by looking at source, exactly what is
being compiled. You need to start at the very top and look at every line
code and keep track of all the macros. But people aren't compilers.
So I think those rules about numbers of parameters, lines in a function
and so on, are pointless given the endless possibilities of C.
MY C code is very conservative, and would be very easy to compile,
understand, or translate, as I don't use conditional blocks and rarely
use macros. Most I come across isn't.
> I wonder if anybody has tried to link with the
> depth of nesting directly, although not via the primitive
> max or mean statistics, but via something smarter, such as
> median, or weighted average.
>
> Linus 8-chareater-tab Torvalds was IMHO right when he
> decreed that a function shall not have more then three
> levels of nesting, his enourmous tab serving as a dumb,
> primitive, mechanical, and ugly means of enforsing this
> decree.
Using hardware tabs on a paper teletype, which also limits you to 80
columns (or was it 72?) really was enforcing it mechanically.
> I observe that technological progress provides a basis for a
> sort of programming nazism, where all code is
> unconditionally and obligatorily processed throught a
> pretty- (aka ugly-) -printer before even a review, so that
> the programmer cannot use any formatting whatsoever to
> emphasize structure or better express his intent.
>
> For an example, and the standard if-else-if-else... chain is
> in fact a variant of a switch, and a switch has the
> structure of a flat, two-dimensional table. That said, the
> deeply nested format, often assumed for granted, is wrong (I
> hope everyone reads this group in monospace font):
>
> if( test_1 ) {
> stat_1 } else {
> if( test_2 ) {
> stat_2 } else {
> if( test_3 ) {
> stat_3 } else {
>
You haven't shown the full thing, which is more like this:
if( test_1 ) {
stat_1; } else {
if( test_2 ) {
stat_2; } else {
if( test_3 ) {
stat_3; } else {}}}
Those stat_* may or may not have braces. But the brace here: 'else {
if', if you were to strictly follow certain guidelines, requires the
correct sequence of closing } braces at the end.
Other languages (even C in its preprocessor!) use a special else-if
keyword to allow the chain without an arbitrary level of nesting and
therefore indents (a 100-way chain would need about 100 indents and 100
} near the end).
But C's {...} around single statements (like a nested 'if') is optional...
> and the correct format is flat and table-like:
>
> if( test_1 ) stat_1;
> else if( test_2 ) stat_2;
> else if( test_3 ) stat_3;
... which allows you to write it like this, although usually without
that extra alignment. In theory there is still nesting, but no multiple
}s are needed at the end.
(Another way might be to start off with 'if (0);' then all actual blocks
will start with 'else if', except the optional final 'else' not shown in
your second example.)
> It shorter, clearer, and better structured, because the
> programmer has formatted the code according its intent.
> Observe also the indent of the first `if' to have it aligned
> with the other entries of the table.
A trivial extension to the syntax could have taken care of it too. Like
'elsif', or I also created, elsewhere, this form, although I've never
used it:
case # usual control expression is blank
when test_1 then
stat_1a # no braces or begin-end needed
stat_1b
when test_2 then
stat_2
when test_1 then
stat_3
else
stat_4
end
This has the advantage, like my 'if(0)' idea, that any blocks can be
commented, uncommented, deleted, inserted and moved with greater
freedom, because the first condition+block does not have special syntax.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-09-26 13:57 +0000 |
| Message-ID | <ueuo0h$lfu$1@reader2.panix.com> |
| In reply to | #176436 |
In article <20230926143726.8fd502c51264c4e127203da4@gmail.moc>, Anton Shepelev <anton.txt@gmail.moc> wrote: >Bart: >>[snip] >> Are there are also rules about how many lines in a >> function, and how many modules in a program? > >In fact, there are. There strictest ones I have ever met >with belong to Rebert Martin. In /Clean code/, he proposes >that a function have no more than 20 lines (and at most 3 >parameters!), and a module no more than 200 lines. >Programmers tend to put limits on the complexity of the >lower-level (tactical?) program elements with which they >work, at the expense of higher-level (strategical?) >complexity describing modules/classes/interfaces. > >[snip] > >No, I cannot follow Martin's rules even for 80% of my code, >for various reasons. I cannot have a maximum of three Robert C Martin is, at best, a middling-quality programmer. But more than that, the man is a blowhard and frankly no one should take programming advice from him. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-26 17:14 +0300 |
| Message-ID | <20230926171422.fbc681174edadb9d385a9c0f@gmail.moc> |
| In reply to | #176452 |
Dan Cross: > Robert C Martin is, at best, a middling-quality > programmer. Maybe he is, but how do you come to that conclusion? -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-09-26 14:27 +0000 |
| Message-ID | <ueupor$kiu$1@reader2.panix.com> |
| In reply to | #176453 |
In article <20230926171422.fbc681174edadb9d385a9c0f@gmail.moc>, Anton Shepelev <anton.txt@gmail.moc> wrote: >Dan Cross: > >> Robert C Martin is, at best, a middling-quality >> programmer. > >Maybe he is, but how do you come to that conclusion? By examining his publicly available work, as well as his writing. "Clean Code" in particular is rife with spelling and grammar errors, and one can look at his code on Github. See, for example, this: https://github.com/unclebob/PDP8EmulatorIpad/pull/2 (Here's the original source program: https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c Or, consider this commit: https://github.com/unclebob/PDP8EmulatorIpad/commit/7a80391bdbc1b1d867079392e4bcf98fcad32014 in light of the timing of the above PR. Writing a bad rinkydink little program is one thing; unacknowledged lifting from someone else's work is another.) One can look at other repositories and find similar examples of poor quality code, most of which is small and/or demo-oriented, anyway (he, like Allen Holub and other "Agile Influencers" has very little production-quality code out in the open). He also tends to opine on things he knows very little about. For example, here he rails against static typing: https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html Most of this is simply nonsense, so much so that Shriram Kirhsnamurthi called him out in a quote-tweet: https://twitter.com/shriramkmurthi/status/1136411753590472707 (The context here is that a strong, static type system can render many invalid programs simply unrepresentable, therefore reducing the amount a programmer may have to test, since a large swath of invalid programs can't be written in the first place.) - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-26 15:22 +0000 |
| Message-ID | <yGCQM.35598$ugs.11802@fx36.iad> |
| In reply to | #176454 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <20230926171422.fbc681174edadb9d385a9c0f@gmail.moc>, >Anton Shepelev <anton.txt@gmail.moc> wrote: >>Dan Cross: >> >>> Robert C Martin is, at best, a middling-quality >>> programmer. >> >>Maybe he is, but how do you come to that conclusion? > >By examining his publicly available work, as well as his >writing. > >"Clean Code" in particular is rife with spelling and grammar >errors, and one can look at his code on Github. See, for >example, this: >https://github.com/unclebob/PDP8EmulatorIpad/pull/2 >(Here's the original source program: >https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c What's with the screwy indentation? That's a 'do not hire this guy' flag. Waste of time to bzero the string before constructing it using strcpy, rather than just using snprintf(). Ah, I see your point is that he writes poor code.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-09-26 17:45 +0000 |
| Message-ID | <uev5c1$73g$1@reader2.panix.com> |
| In reply to | #176460 |
In article <yGCQM.35598$ugs.11802@fx36.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <20230926171422.fbc681174edadb9d385a9c0f@gmail.moc>, >>Anton Shepelev <anton.txt@gmail.moc> wrote: >>>Dan Cross: >>> >>>> Robert C Martin is, at best, a middling-quality >>>> programmer. >>> >>>Maybe he is, but how do you come to that conclusion? >> >>By examining his publicly available work, as well as his >>writing. >> >>"Clean Code" in particular is rife with spelling and grammar >>errors, and one can look at his code on Github. See, for >>example, this: >>https://github.com/unclebob/PDP8EmulatorIpad/pull/2 >>(Here's the original source program: >>https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c > >What's with the screwy indentation? That's a 'do not hire this guy' flag. > >Waste of time to bzero the string before constructing it using strcpy, >rather than just using snprintf(). > >Ah, I see your point is that he writes poor code. Indeed! Strangely kind par for the course on people who have strongly held opinions on programming. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-26 17:10 +0200 |
| Message-ID | <ueus9s$2ibi2$1@dont-email.me> |
| In reply to | #176436 |
On 26/09/2023 13:37, Anton Shepelev wrote:
> Bart:
>> Chris M. Thomasson:
>>> Bart:
>>>
>>>> Huh? I didn't realise that was that controversial. I
>>>> don't actually know how many functions I have per
>>>> module, I've never counted!
>>>
>>> I think there is a complexity rule is MISRA that talks
>>> about this...
>>
>> Are there are also rules about how many lines in a
>> function, and how many modules in a program?
>
> In fact, there are. There strictest ones I have ever met
> with belong to Rebert Martin. In /Clean code/, he proposes
> that a function have no more than 20 lines (and at most 3
> parameters!), and a module no more than 200 lines.
> Programmers tend to put limits on the complexity of the
> lower-level (tactical?) program elements with which they
> work, at the expense of higher-level (strategical?)
> complexity describing modules/classes/interfaces.
>
> In a 20-line function, I prefer the local variables declared
> at the beginning, whereas in a 100-line function they are a
> nuisance, but then there are likely other problems with the
> function as well, such as trying to do too much, or
> embracing more than one level of the conceptual task
> hierarchy.
>
> No, I cannot follow Martin's rules even for 80% of my code,
> for various reasons. I cannot have a maximum of three
> parameters without introducing ad-hoc stuctures to group
> them /specificaly/ for that one call. Futhermore, if a
> function returns an error flag, providing error details
> (text, code, or perhaps a stack of text and code records) in
> an output parameter, I am left with but one input parameter
> and one output parameter (because the return value is in
> use) -- clearly not enough. But that rules is possible in
> popular OOP, because classes provide a /lot/ of additional
> context to functions (one huge /self/ parameter), and errors
> are frequently signalled out-or-bandwith, i.e. via
> exceptions (no explicit error code and error info).
>
> Modern languages with multiple returns or tuples provide a
> partial solution, another being to unify error info with the
> result of successful execution in dynamic languages or ones
> with templates (to save the declaring a combined TResult
> type for every function). But then, I loose the whole
> pupose of an error flag -- the ability to invoke funtions
> inside an `if' statement.
>
You realise that in C you can return structs, and thus include status
returns as well as value returns in one item? It is maybe not quite as
convenient in C as in languages supporting multiple return values, but
it is certainly possible.
Still, why are you talking about modern languages and object oriented
programming when you insist on using a language outdated a generation ago?
>> Further, there will be more complexity due to interactions
>> or interfaces between functions and between modules being
>> exposed, that could have been kept private.
>
> I believe that with a good architecture this kind of higher-
> level, strategical complexity is easier to manage, where I
> agree with the mainstream consensus. The essence is exactly
> to escalate tatcical low-level devilish complexity into the
> cloulds, and there to deal with it with more elbow-room.
>
> There are many measures of code/program/architecture
> complexity. I wonder if anybody has tried to link with the
> depth of nesting directly, although not via the primitive
> max or mean statistics, but via something smarter, such as
> median, or weighted average.
>
> Linus 8-chareater-tab Torvalds was IMHO right when he
> decreed that a function shall not have more then three
> levels of nesting, his enourmous tab serving as a dumb,
> primitive, mechanical, and ugly means of enforsing this
> decree.
No, Linus was wrong - as he is on many things. (He's right on many
things too, of course.) We are not using typewriters, we are not using
80x25 character displays, and we do not need to have pointless
limitations. I don't advocate for deeply nested or overly complex
functions, of course - I advocate for clear code with immediately
obvious blocks indicated by braces /and/ indents. And if clear code
requires more than 3 levels of nesting, use that.
>
> I observe that technological progress provides a basis for a
> sort of programming nazism, where all code is
> unconditionally and obligatorily processed throught a
> pretty- (aka ugly-) -printer before even a review, so that
> the programmer cannot use any formatting whatsoever to
> emphasize structure or better express his intent.
>
> For an example, and the standard if-else-if-else... chain is
> in fact a variant of a switch, and a switch has the
Not in C.
> structure of a flat, two-dimensional table. That said, the
> deeply nested format, often assumed for granted, is wrong (I
> hope everyone reads this group in monospace font):
>
> if( test_1 ) {
> stat_1 } else {
> if( test_2 ) {
> stat_2 } else {
> if( test_3 ) {
> stat_3 } else {
I have never seen if-else chains formatted that way - it is clearly
incorrect indentation.
>
> and the correct format is flat and table-like:
>
> if( test_1 ) stat_1;
> else if( test_2 ) stat_2;
> else if( test_3 ) stat_3;
>
These are both wrong :-)
if (test1) {
stat_1;
} else if (test2) {
stat_2;
} else if (test3) {
stat_3;
} else {
...
}
That is clearer than yours, and far more maintainable. And any coding
standard with a care for safety, security or reliability, (such as MISRA
or JSF-AV mentioned in this thread) will insist on the braces here.
> It shorter, clearer, and better structured, because the
> programmer has formatted the code according its intent.
> Observe also the indent of the first `if' to have it aligned
> with the other entries of the table.
That's a strawman argument, because no one would ever write an if-else
chain the way you first suggested.
>
> Coding standard rarery (if ever) take these semantical
> (intent) and perceptinve (table) considerations into accout,
> whereas automatic linters or pretty-printers supply the
> necessary technology to implement this Nazism.
>
I have no idea what you are trying to say there.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-26 08:29 -0700 |
| Message-ID | <499dbc5e-44f7-45a6-bb0b-69ec6933d0a6n@googlegroups.com> |
| In reply to | #176458 |
On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote: > On 26/09/2023 13:37, Anton Shepelev wrote: > > > > Linus 8-chareater-tab Torvalds was IMHO right when he > > decreed that a function shall not have more then three > > levels of nesting, his enourmous tab serving as a dumb, > > primitive, mechanical, and ugly means of enforsing this > > decree. > No, Linus was wrong - as he is on many things. (He's right on many > things too, of course.) We are not using typewriters, we are not using > 80x25 character displays, and we do not need to have pointless > limitations. I don't advocate for deeply nested or overly complex > functions, of course - I advocate for clear code with immediately > obvious blocks indicated by braces /and/ indents. And if clear code > requires more than 3 levels of nesting, use that. > Rule of three. Three levels of nesting or indirection. Because we live in a three dimensional world.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 11:04 +0200 |
| Message-ID | <uf0r7l$30kt2$1@dont-email.me> |
| In reply to | #176461 |
On 26/09/2023 17:29, Malcolm McLean wrote: > On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote: >> On 26/09/2023 13:37, Anton Shepelev wrote: >>> >>> Linus 8-chareater-tab Torvalds was IMHO right when he >>> decreed that a function shall not have more then three >>> levels of nesting, his enourmous tab serving as a dumb, >>> primitive, mechanical, and ugly means of enforsing this >>> decree. >> No, Linus was wrong - as he is on many things. (He's right on many >> things too, of course.) We are not using typewriters, we are not using >> 80x25 character displays, and we do not need to have pointless >> limitations. I don't advocate for deeply nested or overly complex >> functions, of course - I advocate for clear code with immediately >> obvious blocks indicated by braces /and/ indents. And if clear code >> requires more than 3 levels of nesting, use that. >> > Rule of three. Three levels of nesting or indirection. Because we live in a three > dimensional world. Rule of seven. Seven levels of nesting or indirection. Because we have seven days in the week. See? Anyone can write complete and utter drivel, with totally nonsensical "justifications". Don't you ever get tired of spouting these insane platitudes, as though you imagine yourself as some kind of holy prophet of programming? Your track record here, and the way you make such pronouncements as if you were revealing the hidden laws of the universe, makes people assume you are wrong. Even though you are sometimes accidentally correct, or at least partially right, the gut reaction is that Malcolm is pontificating again, so its nonsense. Please put a post-it note on the top of your screen - "There is no rule of three". Maybe over time it will sink in.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-27 03:37 -0700 |
| Message-ID | <2aa534e2-1567-43d5-9f36-7c4266e3b9e1n@googlegroups.com> |
| In reply to | #176519 |
On Wednesday, 27 September 2023 at 10:05:12 UTC+1, David Brown wrote: > On 26/09/2023 17:29, Malcolm McLean wrote: > > On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote: > >> On 26/09/2023 13:37, Anton Shepelev wrote: > >>> > >>> Linus 8-chareater-tab Torvalds was IMHO right when he > >>> decreed that a function shall not have more then three > >>> levels of nesting, his enourmous tab serving as a dumb, > >>> primitive, mechanical, and ugly means of enforsing this > >>> decree. > >> No, Linus was wrong - as he is on many things. (He's right on many > >> things too, of course.) We are not using typewriters, we are not using > >> 80x25 character displays, and we do not need to have pointless > >> limitations. I don't advocate for deeply nested or overly complex > >> functions, of course - I advocate for clear code with immediately > >> obvious blocks indicated by braces /and/ indents. And if clear code > >> requires more than 3 levels of nesting, use that. > >> > > Rule of three. Three levels of nesting or indirection. Because we live in a three > > dimensional world. > Rule of seven. Seven levels of nesting or indirection. Because we have > seven days in the week. > > See? Anyone can write complete and utter drivel, with totally > nonsensical "justifications". > > Don't you ever get tired of spouting these insane platitudes, as though > you imagine yourself as some kind of holy prophet of programming? Your > track record here, and the way you make such pronouncements as if you > were revealing the hidden laws of the universe, makes people assume you > are wrong. Even though you are sometimes accidentally correct, or at > least partially right, the gut reaction is that Malcolm is pontificating > again, so its nonsense. > > Please put a post-it note on the top of your screen - "There is no rule > of three". Maybe over time it will sink in. > It is odd that singificant figures in the programming world seem to have a habit of agreeing with me. Maybe consider that maybe Malcolm is more correct than he is wrong and that you, David Brown, can sometimes learn something. (Nesting, indirection, and dimensioning are all related to each other).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 17:03 +0200 |
| Message-ID | <uf1g7o$34tu1$1@dont-email.me> |
| In reply to | #176525 |
On 27/09/2023 12:37, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 10:05:12 UTC+1, David Brown wrote:
>> On 26/09/2023 17:29, Malcolm McLean wrote:
>>> On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote:
>>>> On 26/09/2023 13:37, Anton Shepelev wrote:
>>>>>
>>>>> Linus 8-chareater-tab Torvalds was IMHO right when he
>>>>> decreed that a function shall not have more then three
>>>>> levels of nesting, his enourmous tab serving as a dumb,
>>>>> primitive, mechanical, and ugly means of enforsing this
>>>>> decree.
>>>> No, Linus was wrong - as he is on many things. (He's right on many
>>>> things too, of course.) We are not using typewriters, we are not using
>>>> 80x25 character displays, and we do not need to have pointless
>>>> limitations. I don't advocate for deeply nested or overly complex
>>>> functions, of course - I advocate for clear code with immediately
>>>> obvious blocks indicated by braces /and/ indents. And if clear code
>>>> requires more than 3 levels of nesting, use that.
>>>>
>>> Rule of three. Three levels of nesting or indirection. Because we live in a three
>>> dimensional world.
>> Rule of seven. Seven levels of nesting or indirection. Because we have
>> seven days in the week.
>>
>> See? Anyone can write complete and utter drivel, with totally
>> nonsensical "justifications".
>>
>> Don't you ever get tired of spouting these insane platitudes, as though
>> you imagine yourself as some kind of holy prophet of programming? Your
>> track record here, and the way you make such pronouncements as if you
>> were revealing the hidden laws of the universe, makes people assume you
>> are wrong. Even though you are sometimes accidentally correct, or at
>> least partially right, the gut reaction is that Malcolm is pontificating
>> again, so its nonsense.
>>
>> Please put a post-it note on the top of your screen - "There is no rule
>> of three". Maybe over time it will sink in.
>>
> It is odd that singificant figures in the programming world seem to have a
> habit of agreeing with me.
> Maybe consider that maybe Malcolm is more correct than he is wrong and
> that you, David Brown, can sometimes learn something.
>
I've considered it, and I have concluded that you are wrong more often
than you are right in these things. Or, to be more precise, you are
wrong in your absolutist ideas ("three is good, four is bad"),
unjustified in your rationalisation for your ideas (they are often
totally absurd), and your appeals to authority never hold up.
I am quite happy to agree that too many levels of nesting makes code
harder to understand. I am happy to agree that for a lot of code, three
levels of nesting (not including indents for functions, classes, etc.)
is usually sufficient. I can even agree that deeper nesting than that
may be a sign that the function would be better if it were organised
somewhat differently, or split up.
But that does /not/ mean that three levels of nesting is any kind of
absolute limit, or cut-off point. It does not mean that three levels is
always clear, or that four levels are always bad - it merely means that
too many levels makes code harder to follow.
There is no mythical "rule of three" here, or anywhere else. You cannot
simply take everything that you can think of that is related to the
number 3, and lump it together as though there is a divine purpose
linking them all. It's the same nutjob mentality that gives us
flat-earthers.
> (Nesting, indirection, and dimensioning are all related to each other).
No, they are not.
None of this means you are always wrong, nor does it mean I can't learn
from things you write. But it does mean that it can take some effort to
separate your fairytale nonsense from your rational and relevant points.
You have plenty of useful and interesting things to say, and things we
/can/ learn from. Please stop distracting from that with your imaginary
rules and even more unrealistic explanations for them.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-27 08:35 -0700 |
| Message-ID | <bb817356-d077-49c2-8bf4-c3f9774aabffn@googlegroups.com> |
| In reply to | #176538 |
On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote: > On 27/09/2023 12:37, Malcolm McLean wrote: > > > (Nesting, indirection, and dimensioning are all related to each other). > No, they are not. > You haven't thought this through, have you?
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web