[TangerineSDR] [EXTERNAL] Re: Fwd: Proposal: HamSCI Code Review

Rob Wiesler robert.wiesler at case.edu
Thu Aug 13 21:56:49 EDT 2020


On Thu, Aug 13, 2020 at 6:33 PM Dr. Nathaniel A. Frissell Ph.D. via
TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
> There is another way to look at this code review. For our particular team, it may make less sense for this to be a "code review" in the formal sense of guaranteeing strict adherence to a particular standard.

Having "a standard" or not is orthogonal to performing code reviews.
Code reviews are just a way to get more eyes on new code, with
immediate feedback in both directions (the reviewers can ask "what is
this code supposed to be doing?", "why are you not using Foo Pattern
here, is there a reason for that?", etc., the reviewee can ask "is
there a better way to do this?", "does this code look correct?",
etc.).  The "standards" they adhere to are just the accumulated wisdom
of the participants, which I've already asserted to be better than any
coding standards document.

> Rather, this could be a time for sharing ideas, giving tutorials, and asking for help. Manu people here are new to coding, or working in a particular language.
>
> Why don't we make this more of an interactive lab or sharing time?

Well, we could have that too, but the point of a code review is to
polish code (ideally with some amount of self-improvement so you're
not finding the same flaws in new code every session).  If it's just a
yak session, the code doesn't get polished.  That's not to say that
each session has to be laser-focused on some specific code - in my
experience, code review sessions have been a great opportunity for
their participants to learn all sorts of related or even unrelated
things.

Let's not bikeshed this too much, please.  Aidan has this figured out.

(I should mention that my name is in the hat for this as a reviewer.
As I've mentioned before, I find it difficult to participate in
TangerineSDR/HamSCI projects when they're all done over Zoom (or
Teamspeak, as they used to be) so I'm hoping some code review sessions
will not be.  For those of you on this list who don't know me, I'm a
software engineer at a small embedded systems shop, and our product is
very similar to the TangerineSDR (just with less-fun radios, no FPGA,
and significantly more complicated networking), and I'm the one who
maintains its operating system distributions (an old OpenEmbedded
derivative we're phasing out, and a new Debian derivative), build
systems, and nearly all of its custom software.)



More information about the TangerineSDR mailing list