Re: Naming typedefs



On Sep 2, 6:24 pm, Måns Rullgård <m...@xxxxxxxxx> wrote:
Francine.Ne...@xxxxxxxxxxxxxx writes:
On Sep 2, 1:40 pm, Måns Rullgård <m...@xxxxxxxxx> wrote:
Declaring typedefs for structs in general does not help in solving any
such fundamental problems. Doing so only adds complexity with no
functional gain.

I'm never going to stop typedef'ing structs for the same reason I'm

All I've been trying to say is that there are no technical reasons to
routinely typedef structs; it is purely a matter of taste. I also
gave reasons why I prefer not to use unnecessary typedefs. The OP was
asking for advice on naming conventions, and I responded with what I
consider good practice that works well for me. You apparently
disagree, and you are free to do so, but this last post of yours
didn't add anything relevant to the discussion.

On the contrary, it refuted your point that there is no gain in
exchange for the "extra complexity" that you assert exists:
specifically, you gain by saving typing seven characters every time
you declare a variable, function or parameter whose type is a struct.

If you nothing more
to add, please just refrain from posting. You might as well be
arguing whether red or blue is the prettier colour. We all have our
own personal favourite colours, but sometimes one colour is better
suited than another for purely technical reasons, such as contrast (or
camouflage).

Well, I was the OP, and I seem to have provoked a religious war rather
than a civil discussion about type-naming conventions, so at this
point I abandon ship.

never going to write code like
for(array_index_counter=0 ; array_index_counter<MAX_INDEX_OF_ARRAY ;
array_index_counter++) {
/* stuff */
}

Are you referring to the hideous formatting, the overly long variable
names, or to for loops in general?

--
Måns Rullgård
m...@xxxxxxxxx


.



Relevant Pages

  • Re: Naming typedefs
    ... Doing so only adds complexity with no ... functional gain. ... All I've been trying to say is that there are no technical reasons to ...
    (comp.unix.programmer)
  • Re: Using shell commands versus C equivalents
    ... On Wed, 13 Jun 2007, Tim Kientzle wrote: ... complexity for no gain, it might actually slow it down. ... As Joerg said, though, you're not likely to gain much from ... pkg_install is almost entirely disk bound. ...
    (freebsd-hackers)
  • Re: Using shell commands versus C equivalents
    ... complexity for no gain, it might actually slow it down. ... I'll take a look in gdb at the size of each dependency and then confer with Kirill about that a bit more. ... As Joerg said, though, you're not likely to gain much from ... pkg_install is almost entirely disk bound. ...
    (freebsd-hackers)
  • Re: [v4l-dvb-maintainer] Re: [PATCH 08/18] V4L/DVB (4734): Tda826x: fix frontend selection f
    ... Yes, it adds some complexity. ... The gain, however, is to allow having ... even more complex and only worked for a few card drivers that specially ... There is a boilerplate #if in the font-end header file ...
    (Linux-Kernel)