Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101543 > unrolled thread
| Started by | "Fernando D. Bozzo" <fdbozzo@gmail.com> |
|---|---|
| First post | 2017-01-12 11:48 -0800 |
| Last post | 2017-01-13 23:46 +0800 |
| Articles | 10 on this page of 190 — 24 participants |
Back to article view | Back to comp.lang.c
Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 11:48 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 11:58 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 01:35 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 17:43 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 02:19 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:26 -0800
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 00:28 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:56 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 12:23 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:49 +0100
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-13 05:03 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 16:00 +0100
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-13 18:28 -0800
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 18:58 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 14:07 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:31 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 09:20 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 18:47 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 10:02 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 21:42 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 12:55 -0800
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 13:09 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 21:01 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 17:48 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:35 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 19:45 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:51 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 21:12 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:53 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-13 08:59 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 18:48 +0100
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 18:03 -0800
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:05 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-13 19:30 +1300
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 13:00 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 10:43 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:52 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 12:56 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 10:54 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-13 22:00 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 11:18 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 00:59 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 17:12 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 14:47 +1300
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 01:36 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 11:26 +0000
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:11 +0000
Re: Naming convention for structs and types Parity Error <kgf@quiscurat.net> - 2017-01-15 08:33 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-15 02:52 -0800
Re: Naming convention for structs and types Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-15 14:48 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:07 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 14:40 +1300
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 11:28 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 11:48 +0000
Re: Naming convention for structs and types Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-14 13:17 +0100
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 14:21 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 13:27 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 14:00 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 14:11 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 14:12 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 16:18 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 16:31 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 18:50 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 19:48 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:15 +1300
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 20:12 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 23:31 +0100
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 10:28 -0800
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 18:52 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:49 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:41 -0800
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 23:03 +0000
Re: Naming convention for structs and types Parity Error <kgf@quiscurat.net> - 2017-01-15 08:41 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-16 20:01 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 00:19 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 00:29 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 09:12 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 11:59 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 13:16 +0000
OT: Bash tab completion (was: Naming convention for structs and types) Andreas Perstinger <andipersti@gmail.com> - 2017-01-17 13:27 +0000
Re: OT: Bash tab completion BartC <bc@freeuk.com> - 2017-01-17 13:59 +0000
Re: OT: Bash tab completion David Brown <david.brown@hesbynett.no> - 2017-01-17 15:49 +0100
Re: OT: Bash tab completion fir <profesor.fir@gmail.com> - 2017-01-17 07:06 -0800
Re: OT: Bash tab completion fir <profesor.fir@gmail.com> - 2017-01-17 07:43 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 15:18 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 19:26 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:53 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-17 20:56 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 21:38 +0000
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-17 14:22 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-17 23:43 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 00:33 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 11:03 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 12:15 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 13:59 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 15:45 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 17:28 +0100
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-18 09:30 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 23:18 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 21:22 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 12:47 +0100
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-18 08:11 -0800
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 17:17 +0000
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-18 09:47 -0800
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:20 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 22:26 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 00:31 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-18 15:41 -0800
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 23:58 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-17 11:49 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:56 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-17 13:18 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 12:50 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 07:51 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 19:50 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:59 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:51 +1300
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:15 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-19 07:52 +1300
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:09 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 13:26 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 08:10 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 12:28 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:17 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 15:12 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:31 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 16:03 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 15:57 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-14 13:29 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 10:45 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 12:19 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 15:22 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 16:35 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-17 17:02 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-17 20:57 +1300
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-17 08:47 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 08:03 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 07:04 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 08:01 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 11:47 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 22:16 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 15:44 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:59 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 04:42 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-19 07:57 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 11:22 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 13:36 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 05:07 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 16:09 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 07:36 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 17:32 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:55 +1300
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-19 22:28 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-20 08:36 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-20 04:27 -0800
Re: Naming convention for structs and types luser droog <luser.droog@gmail.com> - 2017-01-12 12:01 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 20:11 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 12:50 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 21:02 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 13:26 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 21:35 +0000
Re: Naming convention for structs and types luser droog <luser.droog@gmail.com> - 2017-01-12 16:37 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:57 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-13 16:38 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 17:52 +0100
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 20:07 +0000
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-12 12:45 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 13:01 -0800
Re: Naming convention for structs and types jadill33@gmail.com - 2017-01-12 13:57 -0800
Re: Naming convention for structs and types John Bode <jfbode1029@gmail.com> - 2017-01-12 13:59 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 15:08 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 10:33 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 15:20 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 21:31 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-13 19:43 +1300
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 01:00 -0800
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-13 13:03 -0500
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 16:02 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 13:36 +0100
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-14 05:22 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 17:27 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 21:05 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 09:48 +0100
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-19 13:31 -0500
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 21:18 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-22 17:10 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-22 18:27 +0100
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-13 12:49 -0500
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 09:55 -0800
Re: Naming convention for structs and types "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-01-13 23:46 +0800
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-14 17:27 +0100 |
| Message-ID | <o5djf9$ct7$1@dont-email.me> |
| In reply to | #101750 |
On 14/01/17 14:22, Fernando D. Bozzo wrote:
> El sábado, 14 de enero de 2017, 13:36:36 (UTC+1), David Brown
> escribió:
>> On 13/01/17 19:03, James Kuyper wrote:
>>> On 01/13/2017 04:00 AM, Fernando D. Bozzo wrote: ...
>>>> I'm trying to mentally map some things between FoxPro
>>>> (4th.gen.lang), which is what I know best for now, and C,
>>>> because over the years I've switched from structured
>>>> programming (xBase at 80's) mindset to OOP at 90's and for most
>>>> things I like the OOP approach, clean concepts and
>>>> maintanability.
>>>>
>>>> For example, in VFP you have less data types than in C, so the
>>>> recommended naming convention is the Hungarian which precedes
>>>> any var name with the scope+type+var.name, like:
>>>>
>>>> lcName => local/character/Name ldBirth => local/date/Birth
>>>> toParams => local parameter/object/Params
>>>
>>> Hungarian notation has been proposed for and used in C
>>> programming, as well. Many people adopted the practice, and many
>>> still use it, but I don't think it's really caught on - I think
>>> there's a widespread (but certainly NOT universal) opinion that
>>> it was a bad idea.
>>
>> There are two types of Hungarian notation. "Systems Hungarian
>> notation" is when you name your variables or functions in terms of
>> the types. "unsigned long ulCount;", and so on. It was popular on
>> Windows for a while, and is also used in some embedded programming.
>> It made sense when it was invented for BCPL which had no types, and
>> has some merit if you are limited to poor editors/IDEs and small
>> screen space (such as in the days of DOS and early Windows) as you
>> often have no convenient access to the declarations of variables
>> and functions. But for most work now you have easy access to the
>> declarations, and thus little use for cluttering your names with
>> duplicate information. And there is a widespread (but
>> unfortunately not universal) opinion that unnecessary clutter is
>> bad.
>>
>> I find two cases of "Systems Hungarian" particularly annoying. One
>> is its use in function names. Because C has nothing like
>> namespaces it is common to prefix names in a library, module, or
>> other grouping - queuePush(), queuePop(), queueFlush() for example.
>> But if you use Systems Hungarian, you lose that nice grouping as
>> they are now named bQueuePush(), iQueuePop() and vQueueFlush() for
>> returning bool, int and void.
>>
>> The second annoying case is prefix "g" for globals and "l" for
>> local variables. If you can't see the definition of your local
>> variable your function is too long, and if you don't already know
>> such fundamental aspects of your variables, you should not be using
>> them!
>>
> <snip>
>
> Hi David:
>
> Thanks for your answer, didn't know that existed 2 types of this
> notation, just used the System one I now know.
The name "Hungarian notation" can be used for many things - I'm sure you
can think of other uses too, and give them different names.
>
> When you are using non-strict typed languages (like xBase) it's
> really useful to use this notation, because the same variable can be
> of type DATE but later can be of type CHAR or FLOAT, so keep some
> safety which can't be forced by the compiler, this naming really help
> developers to not confuse them.
Yes, that's a little like BCPL which did not have types and was why the
notation was invented (if my history here is correct). I haven't seen
it much used in Python, however, even though you don't declare the types
of variables. (In Python, objects all have types - but you declare
variables or their types before use.)
>
> (I'm talking from the xBase data types perspective here, because I
> know that at the end the data type is only numeric or char.)
>
> One of many cases in which this is useful is when dealing with dates,
> which in xBase can be used in 3 different ways: - Julian dates
> (numeric) => You need to convert it to date - Char dates
> ("2017/01/14") => You need to convert it to date - Standard dates
> ({^2017/01/14}) => {^2017/02/28} + 1 will return {^2017/03/01}
>
> So, if yout program receive a date from the DOS command line, it
> always will be char (as every other parameter received in the same
> way), so you define your parameter as tcBirthday, but then you
> convert to xBase date so you get ldBirthday and this way you never
> mix tcBirthday with ldBirthday and you know some info about them:
>
> - tcBirthday is a parameter (t) of type character (c) meant to store
> a birthday - ldBirthday is a (l)ocal variable of type date meant to
> store a birthday
>
> If you add that intellisense doesn't let you know the type of the
> data (except when debugging), thes this naming convention is almost
> critical to use.
>
That sounds like a reasonable use of the notation. If it adds helpful
information that is not part of the language itself, that's good. If it
duplicates something that is more accurately and reliably expressed in
the language (such as the type in C), it's bad.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-18 21:05 +0000 |
| Message-ID | <587fd80a.14019140@news.xs4all.nl> |
| In reply to | #101742 |
David Brown <david.brown@hesbynett.no> wrote: > There are two types of Hungarian notation. "Systems Hungarian notation" > is when you name your variables or functions in terms of the types. > "unsigned long ulCount;", and so on. It was popular on Windows for a > while, and is also used in some embedded programming. It made sense > when it was invented for BCPL which had no types, and has some merit if > you are limited to poor editors/IDEs and small screen space (such as in > the days of DOS and early Windows) as you often have no convenient > access to the declarations of variables and functions. But for most > work now you have easy access to the declarations, and thus little use > for cluttering your names with duplicate information. And there is a > widespread (but unfortunately not universal) opinion that unnecessary > clutter is bad. > > I find two cases of "Systems Hungarian" particularly annoying. One is > its use in function names. Because C has nothing like namespaces it is > common to prefix names in a library, module, or other grouping - > queuePush(), queuePop(), queueFlush() for example. But if you use > Systems Hungarian, you lose that nice grouping as they are now named > bQueuePush(), iQueuePop() and vQueueFlush() for returning bool, int and > void. > > The second annoying case is prefix "g" for globals and "l" for local > variables. If you can't see the definition of your local variable your > function is too long, and if you don't already know such fundamental > aspects of your variables, you should not be using them! The third, and most important, annoying case is when it's used for members of structs or API variables which later, for whatever reason, need to change type. You are then left with the choice between making the prefix not match the actual type - which is Bad - or leaving the old member/variable where it is and adding a new one - which is wasteful. This has bitten the Windows API in the arse something dreadful. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-19 09:48 +0100 |
| Message-ID | <o5pud5$898$1@dont-email.me> |
| In reply to | #102153 |
On 18/01/17 22:05, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> There are two types of Hungarian notation. "Systems Hungarian notation" >> is when you name your variables or functions in terms of the types. >> "unsigned long ulCount;", and so on. It was popular on Windows for a >> while, and is also used in some embedded programming. It made sense >> when it was invented for BCPL which had no types, and has some merit if >> you are limited to poor editors/IDEs and small screen space (such as in >> the days of DOS and early Windows) as you often have no convenient >> access to the declarations of variables and functions. But for most >> work now you have easy access to the declarations, and thus little use >> for cluttering your names with duplicate information. And there is a >> widespread (but unfortunately not universal) opinion that unnecessary >> clutter is bad. >> >> I find two cases of "Systems Hungarian" particularly annoying. One is >> its use in function names. Because C has nothing like namespaces it is >> common to prefix names in a library, module, or other grouping - >> queuePush(), queuePop(), queueFlush() for example. But if you use >> Systems Hungarian, you lose that nice grouping as they are now named >> bQueuePush(), iQueuePop() and vQueueFlush() for returning bool, int and >> void. >> >> The second annoying case is prefix "g" for globals and "l" for local >> variables. If you can't see the definition of your local variable your >> function is too long, and if you don't already know such fundamental >> aspects of your variables, you should not be using them! > > The third, and most important, annoying case is when it's used for > members of structs or API variables which later, for whatever reason, > need to change type. You are then left with the choice between making > the prefix not match the actual type - which is Bad - or leaving the old > member/variable where it is and adding a new one - which is wasteful. > > This has bitten the Windows API in the arse something dreadful. > Agreed. I also see this with other syntactic conventions such as all-caps for enum constants and #define'd constants. What do you do if one of these is changed to a "static const int" ? Or vice versa, when you try to use "static const int" first to be a little more modern and structured, but later find C's const is not really as constant as you'd like and you have to change to a #define'd literal? To code that /uses/ these values, it does not matter at all whether they are "static const" or #define'd constants (assuming both are allowed in that context). But after the change you must either rename every use, or have inconsistent conventions.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-19 13:31 -0500 |
| Message-ID | <o5r0jl$21q$1@dont-email.me> |
| In reply to | #102172 |
On 01/19/2017 03:48 AM, David Brown wrote: ... > I also see this with other syntactic conventions such as all-caps for > enum constants and #define'd constants. What do you do if one of these > is changed to a "static const int" ? ... I keep it as ALL CAPS, which is exactly what I would have done if it had been defined "static const int" in the first place. > ... Or vice versa, when you try to use > "static const int" first to be a little more modern and structured, but > later find C's const is not really as constant as you'd like and you > have to change to a #define'd literal? To code that /uses/ these > values, it does not matter at all whether they are "static const" or > #define'd constants (assuming both are allowed in that context). But > after the change you must either rename every use, or have inconsistent > conventions. My convention is consistent: compile-time constants are named in all caps, regardless of the way that they are implemented, whether as #definitions, enumeration constants, or static const object identifiers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-19 21:18 +0100 |
| Message-ID | <o5r6ru$r9b$1@dont-email.me> |
| In reply to | #102186 |
On 19/01/17 19:31, James Kuyper wrote: > On 01/19/2017 03:48 AM, David Brown wrote: > ... >> I also see this with other syntactic conventions such as all-caps for >> enum constants and #define'd constants. What do you do if one of these >> is changed to a "static const int" ? ... > > I keep it as ALL CAPS, which is exactly what I would have done if it had > been defined "static const int" in the first place. > >> ... Or vice versa, when you try to use >> "static const int" first to be a little more modern and structured, but >> later find C's const is not really as constant as you'd like and you >> have to change to a #define'd literal? To code that /uses/ these >> values, it does not matter at all whether they are "static const" or >> #define'd constants (assuming both are allowed in that context). But >> after the change you must either rename every use, or have inconsistent >> conventions. > > My convention is consistent: compile-time constants are named in all > caps, regardless of the way that they are implemented, whether as > #definitions, enumeration constants, or static const object identifiers. > That at least is consistent. I don't like all-caps (for most purposes), but that is a matter of preference.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-22 17:10 +0000 |
| Message-ID | <5884e593.18926968@news.xs4all.nl> |
| In reply to | #102172 |
David Brown <david.brown@hesbynett.no> wrote: > On 18/01/17 22:05, Richard Bos wrote: > > The third, and most important, annoying case is when it's used for > > members of structs or API variables which later, for whatever reason, > > need to change type. You are then left with the choice between making > > the prefix not match the actual type - which is Bad - or leaving the old > > member/variable where it is and adding a new one - which is wasteful. > > > > This has bitten the Windows API in the arse something dreadful. > > Agreed. > > I also see this with other syntactic conventions such as all-caps for > enum constants and #define'd constants. What do you do if one of these > is changed to a "static const int" ? Or vice versa, when you try to use > "static const int" first to be a little more modern and structured, but > later find C's const is not really as constant as you'd like and you > have to change to a #define'd literal? To code that /uses/ these > values, it does not matter at all whether they are "static const" or > #define'd constants (assuming both are allowed in that context). But > after the change you must either rename every use, or have inconsistent > conventions. I don't see that as as much of a problem. First because, as you note, it doesn't really matter that much to well-written user code. Second because, AFAICT, it isn't nearly as common. But most importantly because, frankly, this is implementor error. If you're writing an API, you _do not_ guess at what you need. Finding out, after three years and about three thousand live users, that you should've used a #define instead of a static const int, or /vice versa/, is just a poor show. After three months and a three dozen alpha testers, yeah, fair enough. But by the time it starts to matter to others? No, sorry, you should've done your research. By contrast, the type underlying a struct member or CPU interface type can _and will_ change behind your back, whether you like it or not. If only because new CPUs come along and enlarge their buses. That's not poor research, that's technology moving on, as it will. But that also means that you take into account this advancing technology, and not, ever, using System Hungarian is part of that. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-22 18:27 +0100 |
| Message-ID | <o62pud$fpo$1@dont-email.me> |
| In reply to | #102339 |
On 22/01/17 18:10, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/01/17 22:05, Richard Bos wrote: > >>> The third, and most important, annoying case is when it's used for >>> members of structs or API variables which later, for whatever reason, >>> need to change type. You are then left with the choice between making >>> the prefix not match the actual type - which is Bad - or leaving the old >>> member/variable where it is and adding a new one - which is wasteful. >>> >>> This has bitten the Windows API in the arse something dreadful. >> >> Agreed. >> >> I also see this with other syntactic conventions such as all-caps for >> enum constants and #define'd constants. What do you do if one of these >> is changed to a "static const int" ? Or vice versa, when you try to use >> "static const int" first to be a little more modern and structured, but >> later find C's const is not really as constant as you'd like and you >> have to change to a #define'd literal? To code that /uses/ these >> values, it does not matter at all whether they are "static const" or >> #define'd constants (assuming both are allowed in that context). But >> after the change you must either rename every use, or have inconsistent >> conventions. > > I don't see that as as much of a problem. First because, as you note, it > doesn't really matter that much to well-written user code. Second > because, AFAICT, it isn't nearly as common. But most importantly > because, frankly, this is implementor error. > If you're writing an API, you _do not_ guess at what you need. Finding > out, after three years and about three thousand live users, that you > should've used a #define instead of a static const int, or /vice versa/, > is just a poor show. After three months and a three dozen alpha testers, > yeah, fair enough. But by the time it starts to matter to others? No, > sorry, you should've done your research. I have seen it happen. But I'll happily agree that it is going to be a rare problem. > By contrast, the type underlying a struct member or CPU interface type > can _and will_ change behind your back, whether you like it or not. If > only because new CPUs come along and enlarge their buses. That's not > poor research, that's technology moving on, as it will. But that also > means that you take into account this advancing technology, and not, > ever, using System Hungarian is part of that. > > Richard >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-13 12:49 -0500 |
| Message-ID | <o5b3rn$37h$1@dont-email.me> |
| In reply to | #101581 |
On 01/13/2017 01:43 AM, Ian Collins wrote:
...
> If you are going to use the typedef name, the only reason to name the
> struct is if you want to include it within the structure declaration,
> such as
>
> typedef struct _justfname
> {
> char* value;
> int len;
> struct _justfname* parent;
> } Justfname;
For that kind of purpose, I prefer:
typedef struct Justfname
{
char* value;
int len;
struct Justfname* parent;
} Justfname;
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-13 09:55 -0800 |
| Message-ID | <410cc3d4-5b71-4451-b5c5-91acee137171@googlegroups.com> |
| In reply to | #101628 |
On Friday, January 13, 2017 at 11:49:19 AM UTC-6, James Kuyper wrote:
> For that kind of purpose, I prefer:
>
> typedef struct Justfname
> {
> char* value;
> int len;
> struct Justfname* parent;
> } Justfname;
How about
typedef struct Justfname Justfname;
struct Justfname
{
char* value;
int len;
Justfname* parent;
};
Though it wouldn't really matter what tag was used since there would be
no need to refer to it in any source file except in the above two spots.
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2017-01-13 23:46 +0800 |
| Message-ID | <o5asm1$q3h$1@dont-email.me> |
| In reply to | #101543 |
On 13/1/2017 3:48 AM, Fernando D. Bozzo wrote:
> typedef struct justfname_s
> {
> char *value;
> int len;
> } justfname_t;
> and want to know if it's correct to end struct's names with "_s" and types with "_t".
> In what I've read until now, I didn't see any clear convention.
Check out Hungarian notation:
https://en.wikipedia.org/wiki/Hungarian_notation
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.lang.c
csiph-web