Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #101543 > unrolled thread

Naming convention for structs and types

Back to article view | Back to comp.lang.c

Contents

  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 9 of 10 — ← Prev page 1 … 7 8 [9] 10  Next page →

#101558

On 12/01/17 21:26, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 12/01/17 20:50, Keith Thompson wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>> On 12/01/17 20:01, luser droog wrote:
>>>> <snip>
>>>>>
>>>>> The trailing _t is actually reserved for the implementation,
>>>>
>>>> Certainly true for int*_t and uint*_t, but do you have a citation for
>>>> the more general claim?
>>>
>>> I think it's a POSIX rule.
>>
>> So do I, but I can't find any reference to it in the POSIX Standard.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
>
> Search for the phrase "ANY header" at the bottom of the table in section
> 2.2.2.

Ah yes. Page 451 (of 3718). Sometimes the ISO C Standard looks 
positively friendly. :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101564

On Thursday, January 12, 2017 at 2:11:30 PM UTC-6, Richard Heathfield wrote:
> On 12/01/17 20:01, luser droog wrote:
> <snip>
> >
> > The trailing _t is actually reserved for the implementation,
> 
> Certainly true for int*_t and uint*_t, but do you have a citation for 
> the more general claim?
> 

No. Quite possibly I have borrowed someone's opinion
from somewhere without sufficient skepticism.

[toc] | [prev] | [next] | [standalone]

#101600

On 12/01/17 21:11, Richard Heathfield wrote:
> On 12/01/17 20:01, luser droog wrote:
> <snip>
>>
>> The trailing _t is actually reserved for the implementation,
> 
> Certainly true for int*_t and uint*_t, but do you have a citation for
> the more general claim?
> 

It turns up in a few other standard types (size_t, ptrdiff_t, etc.).  It
is not unreasonable to expect that it is a convention the C standards
would follow in the future for other new types.  But it is not a
convention that is reserved in the C standards.

[toc] | [prev] | [next] | [standalone]

#101615

David Brown <david.brown@hesbynett.no> writes:

> On 12/01/17 21:11, Richard Heathfield wrote:
>> Certainly true for int*_t and uint*_t, but do you have a citation for
>> the more general claim?
>> 
>
> It turns up in a few other standard types (size_t, ptrdiff_t, etc.).  It
> is not unreasonable to expect that it is a convention the C standards
> would follow in the future for other new types.  But it is not a
> convention that is reserved in the C standards.

As I'm sure you're aware, it is reserved in POSIX.1

[toc] | [prev] | [next] | [standalone]

#101617

On 13/01/17 17:38, Gareth Owen wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 12/01/17 21:11, Richard Heathfield wrote:
>>> Certainly true for int*_t and uint*_t, but do you have a citation for
>>> the more general claim?
>>>
>>
>> It turns up in a few other standard types (size_t, ptrdiff_t, etc.).  It
>> is not unreasonable to expect that it is a convention the C standards
>> would follow in the future for other new types.  But it is not a
>> convention that is reserved in the C standards.
> 
> As I'm sure you're aware, it is reserved in POSIX.1
> 

I am aware of that since people mentioned it in this thread, but I was
not aware before that.  I don't program to POSIX, so I'm not fussed
about that - but I appreciate that a great deal of C coding should
follow POSIX standards as well as the C standards.  The original
"general claim" looked like it referred to the C standards rather than
anything else, so it is good to get it all cleared up.

[toc] | [prev] | [next] | [standalone]

#101547

On 12/01/17 19:48, Fernando D. Bozzo wrote:
> Hi:
>
> I made this struct:
>
>
> 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.

The C Standard allows both, although some _t (e.g. size_t, time_t) are 
reserved. The POSIX Standard uses _t quite a lot, and /may/ even reserve 
all _t somewhere in its nearly 4000 pages, although I couldn't find any 
such reservation when I had a quick look.

You could, of course, put the t at the front: t_justfname

This has the merit of being distinctive, while definitely being 
different from any ISO C or POSIX type.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101550

On Thursday, January 12, 2017 at 5:48:38 PM UTC-2, Fernando D. Bozzo wrote:
> Hi:
> 
> I made this struct:
> 
> 
> 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".

You can use the same name.

typedef struct X
{ 
  struct X* pNext;
} X;

[toc] | [prev] | [next] | [standalone]

#101552

"Fernando D. Bozzo" <fdbozzo@gmail.com> writes:
> I made this struct:
>
>
> 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.

Consistency is the most important thing.

If you define a struct with both a tag name (the identifier following
the "struct" keyword) and a typedef name, there's no requirement for
them to differ.  This is perfectly valid:

    typedef struct justfname {
        char *value;    
        int len;
    } justfname;

and lets you refer to the type either as "struct justfname" or as
"justfname".

On the other hand, using the same identifier for both might confuse some
IDEs, particular search facilities.

If you're going to use a typedef, you also need a tag if you want to
refer to the type within its definition, particularly if the type
contains a pointer to itself.  You could write:

    typedef struct {
        char *value;
        int len;
    } justfname;

but it's probably best to be consistent, using a tag whether there
happens to be a pointer member or not.

Finally, you don't have to use a typedef at all:

    struct justfname {
        char *value;
        int len;
    };

The type already has a perfectly good name, "struct justfname".  Adding
a typedef merely gives it a second name, "justfname".  In my opinion,
this saves a little typing, but that's not a good enough reason to give
something two separate names -- and have to think about conventions for
how those names relate to each other.

The counterargument is that it's worthwhile for the type to have a name
that's a single identifier.  That's a perfectly valid position, and
plenty of good programmers use typedefs for that reason.  <OT>And C++
lets you refer to the type as "justfname" even without a typedef.</OT>

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101560

On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
> Hi:
> 
> I made this struct:
> 
> 
> 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.
> 
> Thanks.-

There's not a definitive convention of struct names and typedefs other than
avoiding leading underscores.  It can be frowned upon by some people to use
_t at the end, since the style is used in the C standard, so there's a small
possibility that future standards could clash.

One such contrived scenario would be making an unsigned 32-bit integer in
a struct from 2 unsigned 16-bit integers in a C90 compiler environment and
naming the struct type 'uint32_t'.  Then C99 comes along and if you
#include <stdint.h> ...

Just to add another option is that you can make the struct type typedef
conditional using the preprocessor.

\code
struct justfname_s
{
    char *value;
    int len;
};

#if defined(ALIAS_MY_STRUCT_TYPES)
typedef struct justfname_s justfname_s;
#endif
\endcode

I prefer to use the full struct name in header and implementation files at
the library level, mostly because I run into structs that contain a
pointer to itself (linked list is the classic example), and I want to be
consistent.

I tend to use a typedef for struct types more in application level code
for brevity in files that include the library.  Some struct identifiers
can be absurdly long!  As a general rule, I never make typedef of struct
pointer types because I've been bitten by them too often (but will for
function pointer types, the syntax for declaring a function that returns
a function pointer is just too much for me).

Best regards,
John D.

[toc] | [prev] | [next] | [standalone]

#101561

On Thursday, January 12, 2017 at 1:48:38 PM UTC-6, Fernando D. Bozzo wrote:
> Hi:
> 
> I made this struct:
> 
> 
> 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.
> 
> Thanks.-

There really isn't a clear convention.  POSIX introduced the "_t" 
suffix for type names; it's an open question as to whether that was a good 
idea or not.  After all, we got by *just fine* with plain old "int", 
"float", "double", etc. Not sure what "uint8_t" buys you over just "uint8".  

I'm not fond of the convention myself, at least not anymore.  I would prefer 
typedef names be meaningful in and of themselves without needing any special 
suffix, although I'd use mixed case to set it apart visually:

    typedef struct justfname { char *value; int len } JustFName;
    ...
    JustFName name;

You can't use the tag name "justfname" without the "struct" keyword, so
adding "_s" to the end of it is a bit redundant.  "struct justfname_s" just
adds visual clutter without adding any new information (kind like saying
"PIN number" or "ATM machine").

The main guideline is to be consistent.  If you use the "_t" convention, 
use it consistently.  If you use mixed case, use it consistently.  

[toc] | [prev] | [next] | [standalone]

#101563

John Bode <jfbode1029@gmail.com> writes:
> On Thursday, January 12, 2017 at 1:48:38 PM UTC-6, Fernando D. Bozzo wrote:
>> I made this struct:
>> 
>> 
>> 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.
>
> There really isn't a clear convention.  POSIX introduced the "_t" 
> suffix for type names; it's an open question as to whether that was a good 
> idea or not.  After all, we got by *just fine* with plain old "int", 
> "float", "double", etc. Not sure what "uint8_t" buys you over just "uint8".  

It probably reduced the risk of conflicting with existing identifiers.
Pre-C99 code that used the specific name "uint8_t" was almost certainly
copying the upcoming C9x 8-bit type name; "uint8" might be an object
name.  And it probably borrowed the "_t" suffix convention from POSIX.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101788

John Bode <jfbode1029@gmail.com> writes:

> On Thursday, January 12, 2017 at 1:48:38 PM UTC-6, Fernando D. Bozzo wrote:
>> Hi:
>>
>> I made this struct:
>>
>>
>> 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.
>
> [...]  You can't use the tag name "justfname" without the "struct"
> keyword, so adding "_s" to the end of it is a bit redundant.

Let me offer a counterpoint here.  There can be tag names without
having a 'struct', because 'enum' and 'union' also use tags.  The
namespace for tags is shared between enum, struct and union, so
a trailing "_s" is not as redundant as it might seem:  it serves
to distinguish which of the three categories applies to the tag
in question (and similarly, eg, "_e" or "_u", would identify an
enum or a union).  I recommend adopting some stylistic rule (to
be clear, for tag names) like the "_s" convention for just this
reason.  Personally I think the "_s" differentiator is okay for
this, but the key point is to have a scheme that makes enum tags,
struct tags, and union tags, be distinct from each other.

[toc] | [prev] | [next] | [standalone]

#101824

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Let me offer a counterpoint here.  There can be tag names without
> having a 'struct', because 'enum' and 'union' also use tags.  The
> namespace for tags is shared between enum, struct and union, so
> a trailing "_s" is not as redundant as it might seem:  it serves
> to distinguish which of the three categories applies to the tag
> in question (and similarly, eg, "_e" or "_u", would identify an
> enum or a union).  I recommend adopting some stylistic rule (to
> be clear, for tag names) like the "_s" convention for just this
> reason.  Personally I think the "_s" differentiator is okay for
> this, but the key point is to have a scheme that makes enum tags,
> struct tags, and union tags, be distinct from each other.

I don't see how such a convention is useful.  A tag name must
always be preceded by one of three keywords, struct, union, or enum.
That context is enough to tell you what kind of tag it is.  A _s,
_u, or _e suffix would be purely redundant.

It would let you use the same name for a struct and a union, or a
struct and an enum, but I wouldn't want to do that anyway.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101919

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> Let me offer a counterpoint here.  There can be tag names without
>> having a 'struct', because 'enum' and 'union' also use tags.  The
>> namespace for tags is shared between enum, struct and union, so
>> a trailing "_s" is not as redundant as it might seem:  it serves
>> to distinguish which of the three categories applies to the tag
>> in question (and similarly, eg, "_e" or "_u", would identify an
>> enum or a union).  I recommend adopting some stylistic rule (to
>> be clear, for tag names) like the "_s" convention for just this
>> reason.  Personally I think the "_s" differentiator is okay for
>> this, but the key point is to have a scheme that makes enum tags,
>> struct tags, and union tags, be distinct from each other.
>
> I don't see how such a convention is useful.  A tag name must
> always be preceded by one of three keywords, struct, union, or enum.
> That context is enough to tell you what kind of tag it is.  A _s,
> _u, or _e suffix would be purely redundant.
>
> It would let you use the same name for a struct and a union, or a
> struct and an enum, but I wouldn't want to do that anyway.

Depending on circumstances I might or might not want to use
similar tag names for struct, union, and/or enum types, and it
also might come up accidentally - not everyone knows the rules
that all of those tags share the same name space.  Adding a two
letter suffix costs very little and preserves flexibility going
forward;  also it allows the tags themselves to be used
unambiguously, without needing a struct, enum or union keyword
in front to say which kind of thing it is.  To me the potential
upside, even if it is rare, seems well worth the rather small
cost.  Part of my evaluation supposes that structs are normally
given typedef names - which IMO is good practice regardless -
which correspondingly lowers the cost of having a slightly
longer tag name.

My assessment is the cost/benefit ratio comes down in favor of
lessening potential future problems.  Other people may reach
different conclusions.

[toc] | [prev] | [next] | [standalone]

#101581

On 01/13/17 08:48 AM, Fernando D. Bozzo wrote:
> Hi:
>
> I made this struct:
>
>
> 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.

A lot depends how you use the names.  If you are going to stick to the 
typedef name, I would use "Justfname" and possibly prepend the struct 
name (if I named it) with and underscore to make it awkward to use! I 
like the convention of using a capitalised name for types.

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;

Otherwise I would just write

typedef struct
{
   char* value;
   int len;
} Justfname;


-- 
Ian

[toc] | [prev] | [next] | [standalone]

#101587

El viernes, 13 de enero de 2017, 7:43:08 (UTC+1), Ian Collins  escribió:
> On 01/13/17 08:48 AM, Fernando D. Bozzo wrote:
> > Hi:
> >
> > I made this struct:
> >
> >
> > 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.
> 
> A lot depends how you use the names.  If you are going to stick to the 
> typedef name, I would use "Justfname" and possibly prepend the struct 
> name (if I named it) with and underscore to make it awkward to use! I 
> like the convention of using a capitalised name for types.
> 
> 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;
> 
> Otherwise I would just write
> 
> typedef struct
> {
>    char* value;
>    int len;
> } Justfname;
> 
> 
> -- 
> Ian

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
...

I accept that every language is a different world and have their own rules, and normally one that most languajes have is a naming convention, some of them Microsoft influenced (which is not bad for me) and some Community driven, but the key question for me is that following a clear naming eases team development. 
Even if many times I program alone outside my work, I tend to write code as if it where for another dev, and this good practices and others help a lot.

Back to case of typedef/struct, I have this clear:

1) Struct syntax (alone) require the use of a reference name => struct name {..}
2) Typedef syntax require the name of an alias => typedef int myint
3) The mix of 1 and 2 can be with or without the struct reference name

but I prefer to add always the reference name so it's one error-prone-less way to write in whatever condition, like:

a)
typedef struct _singlell
{
   int key;
   struct _name next;
} singlell

b)
typedef struct _myint
{
   int value;
} myint

In b) I can take out the reference to _myint, but not in a) because the type references itself before the alias is created, so for not thinking every time in this special cases I go for sure and use the reference always, knowing that this will work in every situation.


Thanks all for the tips.

[toc] | [prev] | [next] | [standalone]

#101633

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.

> ...
> I accept that every language is a different world and have their own rules, and normally one that most languajes have is a naming convention, some of them Microsoft influenced (which is not bad for me) and some Community driven, but the key question for me is that following a clear naming eases team development. 
> Even if many times I program alone outside my work, I tend to write code as if it where for another dev, and this good practices and others help a lot.
> 
> Back to case of typedef/struct, I have this clear:
> 
> 1) Struct syntax (alone) require the use of a reference name => struct name {..}

What you call the reference name is referred to by the standard as a
struct tag. Unions and enumerations also have tags.

> 2) Typedef syntax require the name of an alias => typedef int myint
> 3) The mix of 1 and 2 can be with or without the struct reference name
> 
> but I prefer to add always the reference name so it's one error-prone-less way to write in whatever condition, like:
> 
> a)
> typedef struct _singlell
> {
>    int key;
>    struct _name next;

Was that intended to be:
     struct _singlell *next;

Your comments below would make more sense with that declaration.

> } singlell

I would write that this way:

    typedef struct singlell
    {
        int key;
        struct singlell *next;
    } singlell;

> b)
> typedef struct _myint
> {
>    int value;
> } myint
> 
> In b) I can take out the reference to _myint, but not in a) because the type references itself before the alias is created, so for not thinking every time in this special cases I go for sure and use the reference always, knowing that this will work in every situation.

[toc] | [prev] | [next] | [standalone]

#101693

El viernes, 13 de enero de 2017, 19:03:43 (UTC+1), James Kuyper  escribió:
<snip>
> > 
> > a)
> > typedef struct _singlell
> > {
> >    int key;
> >    struct _name next;
> 
> Was that intended to be:
>      struct _singlell *next;

Yes! I mean that. Mistyped it when changing from "_name" to "_singlell" and forgot the internal struct.


> 
> Your comments below would make more sense with that declaration.
> 
> > } singlell
> 
> I would write that this way:
> 
>     typedef struct singlell
>     {
>         int key;
>         struct singlell *next;
>     } singlell;
> 
> > b)
> > typedef struct _myint
> > {
> >    int value;
> > } myint
> > 
> > In b) I can take out the reference to _myint, but not in a) because the type references itself before the alias is created, so for not thinking every time in this special cases I go for sure and use the reference always, knowing that this will work in every situation.

[toc] | [prev] | [next] | [standalone]

#101742

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!


"Apps Hungarian notation" is about adding more application-related 
information to your names, to give information that is not already there 
as part of the type.  The common example is to name strings received 
from the outside as "usName" for "unsafe string", and after it has been 
sanitised (to avoid SQL injection attacks or whatever), you then have 
"ssName" for "safe string".  I haven't seen this sort of notation in use 
as much, though it can be helpful for some code.

[toc] | [prev] | [next] | [standalone]

#101750

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.

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.

(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.

[toc] | [prev] | [next] | [standalone]

Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10  Next page →

Back to top | Article view | comp.lang.c

csiph-web