Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Re: Should we adopt the KD8CEC firmware?
|
Jack Purdum
I agree with Ron, here. Tim's statement:
????It's important to have a *standard* to write to. would be nice, but as we all know, there is a difference between coding style and functionality. Cut-and-paste code is also nice to have, but any code may be useful if you can read and understand it. To me, the litmus test of good code is code that can be read and understood easily. When that's true, it becomes much easier to adapt it to your needs. Simple things like using #define's instead of "magic numbers" make it easier to read and adapt code. (If the IDE had a symbolic debugger, I might use constants, although symbolic constants are typeless and that can be a huge benefit in writing reusable code.) Writing "clever" code is rarely a benefit. Which would you rather read: ?? a = b >> 1; or ?? averageVoltage = baseVoltage / 2;?? // Voltage divider derives average voltage that's applied to pin AVERAGEVOLTAGE Perhaps the only real reason the first version might make sense is to cause some speed gain in the executed code, or perhaps save some memory. Even that, however, often makes no sense because the Gnu compiler is quite good at optimizations. Indeed, my guess is that the two forms above generate exactly the same code. You can examine the *.lst file to get a feel for the final answer. The final step before making it available to the public is to ask yourself: What can I do to make it easier to read and understand this code? If you cannot find changes that enhance readability, it's read for prime time. Even then, readers will have difference preferences on the way they would write the code...that's to be expected. However, the fact they have preferences means they can read, understand, and hopefully use the code. For reasons most can guess, I have not read Ian's code recently, but I'm sure it's readable. The fact that Farhan has even suggested using it as the standard means he's happy with it. If it's possible to conditionally compile the code (e.g., why have a keyer if you know you'll never use CW, leaving some room for additions you know you want), it seems to me to be a moot question. And to those who argue: "But conditional compiles means the users have to be able to change the code!" Yeah, so what? If you can't change the code, you still have several options: 1) accept the radio "as is", 2) learn enough programming to make the changes you want, or 3) pay a programmer to implement the changes you want. Trying to get a boo-hoo from me for people who don't want to invest a weekend in learning how to make such changes is pretty much going to fall on a deaf set of ears. Besides, this kind of programming is going to get more important down the road, not less. May as well bite the bullet and jump on board...you may even find you like it! Jack, W8TEE
On Monday, May 14, 2018, 11:53:47 PM EDT, W2CTX <w2ctx@...> wrote:
Tim ?? When I write software I don't have reuse as part of my mindset.? I try to make something work that is broken or develop something new that does not exist.? Once it is tested it is given to the community to use. ?So if I don't care if others use my code how does that advance the radio?? Well one case comes to mind in that my keyer code had iambic A/B working correctly.? After I published the firmware I believe Ian looked at it.? Now he could not cut-n-paste my code into his firmware because he used different timing and different hardware pins. As he stated in his description of his keyer routine, he looked at my logic and? adapted my code into his. And as all good programmers do gave me acknowledgement in his header of his keyer module. So you don't have to create code that can be cut-n-paste to be useful. rOn On May 14, 2018 at 10:32 PM Tim Gorman wrote: |
to navigate to use esc to dismiss