On Wed, May 11, 2011 at 2:57 PM, Michael D. [email protected]
they end up having these same issues.
I agree, that’s not a bad list. And as you know and Michael pointed out,
these things to have a way of moving by themselves, even if there is a
supposed style structure.
one (I remember having such a discussion with Eric, but I don’t know if a
“formal” document was ever created) – examples off the top of my head
Yes, I’ve had a bit of this in the works but probably need to put more
emphasis on it.
One quick change in definition/language here. We’re not talking about
API, really (some of it is, like the get_ and set_ concept). This is the
coding style. The API is actully fairly stable. This has been one of the
concept behind our versioning. Anything in the master branch maintains a
consistent API. It might not be as consistent between blocks as you
like, but within a block, we don’t change the API until we update a
So what we really want to discuss is the coding style, which will
some common concepts of API’s into blocks.
Just to point out that another issue with changing API’s is that we have
huge base of code, so if we change a style of doing something, it would
nice if we could go back and change everything else to meet the same
Obviously, we don’t necessarily do this.
- underscore_separated_names but never CamelCase;
- separate method names (“get_foo” and “set_foo”) instead of method
overloading (“foo ()” and “foo (foo_type new_foo)”);
- ‘b’ for bit, ‘B’ for byte, ‘c’ for char, ‘f’ for 32-bit IEEE float,
I agree with points 1 and 2 here. In fact, the Qt Gui work that I
is largely in CamelCase (underneath, the GNU Radio interface bits
our style) and I’ve been wanting to change that. But again, it’s a lot
code and not enough time to worry about something like that. I have my
compulsions for this kind of thing, but they only go so far.
On the third point, we have a problem. ‘c’ is used for complex numbers,
what do we do about characters? I think we’re probably ok with bytes
standing in for character almost everywhere, though. We had some
with this naming concept in Volk, where I think we’ve come to a much
verbose but consistent and explicit naming scheme for data types. I
it’s a bit much for GNU Radio blocks, though, and it would involve
GRC makes this concept nice, since all ins and outs are color-coded and
will tell you immediately if there is a problem.
That having been said, we need to be a bit better about this. The
distinction between bits and bytes is important and confusing (because
really packed versus unpacked bytes), and unfortunately the ‘B’ is going
look odd compared to the rest of it. Plus, because its a
the actual data type is a char regardless.
The other issue is vectors. We use v in the name to indicate that a
is used, but does that mean the input or output or both? I suppose we
something like _cvcv for both and _cvc for a vector on the input and
for a vector on the output. I don’t really like how that looks, but it
I’m sure if you (Martin) wanted to do the legwork organizing such a
document, the rest of us would help review and augment it - MLD
We really should put this onto the Wiki. By the way, here’s the Volk