<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I'm in 100% agreement with this opinion but I'll add this:</p>
<p>Embedded code best practices are basically the same as
non-embedded best practices, generally speaking. It's in the
hardware interfacing and low level code that the differences
appear. So it's entirely useful to learn best practices from the
classic sources, whatever they may be. Remember that many
handsomely formatted embedded code bodies of work, especially from
hobbyists and even from pros, don't necessarily represent best
practices.<br>
</p>
<p>But beware: The more resource limited your target is, the more
exceptions to best practices you'll find yourself applying if you
run into said limitations.</p>
<p>JJS<br>
</p>
On 4/21/2020 7:16 AM, <a class="moz-txt-link-abbreviated" href="mailto:music.maker@gte.net">music.maker@gte.net</a> wrote:<br>
<blockquote type="cite"
cite="mid:20200421141642.9A2E1EC22CA@pi4b.lan">
<pre class="moz-quote-pre" wrap="">
"Best practices". For whom? For what? Why? I've seen many suggestions for such expressions and while it sounds academic and proper, reality eventually comes knocking at the door. We tend to push the hardware, so the code that is written isn't always going to be "as the professor taught" nor pretty nor elegant. Sometimes it's dirty and would deserve an F in college, but if it works and is reliable, it's not wrong. As a personal style, I am a comment profusely.
Different environments dictate different approaches. A corporate group project needs practices which don't require a specific key man, rather that can be easily understood by any qualified coder. This can preclude using obscure obfuscated quirks of a device. Single coder projects are very different. The single coder answers to no one but him/herself so best practices are their own definition.
Looking at lots of successful code written by others can be helpful to expose certain practices which can make code more reusable, but not every technique will fit the needs of every coder and every project.
So in my world, there is no set of absolute best practices. Only those which I have found work to my advantage in my workflow.
MTG <a class="moz-txt-link-rfc2396E" href="mailto:grant@musictechnologiesgroup.com"><grant@musictechnologiesgroup.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I'm also interested in this. Sorry, I'm going to add on to your request. :)
...including hardware such as starter SBCs "professional" debugging (NOT
printf styles). And I guess recommendations for sustainable compiler
environments, IDEs, version control. Sustainable meaning the same tool
will work in 5 or 10 years and not want to update every time I use it.
Maybe someone can suggest some electronic music code online that seems
to be written to "best practices" standards?
On 4/21/2020 5:36 AM, Spiros Makris wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hello list,
IÂ want to improve my coding habits so that my results will stay
maintainable and easy to mod/reuse in the future. The scope of my
applications (thus far) is sequencing and other similar low frequency
control/real time devices. I use the arduino platform a lot for it's
incredible simplicity and driver availability (I love you Teensy) but
I'm trying to transition to STM32 eventually, seeing it as a more
"serious" and professional platform. In both cases I use C/C++.
I was officially taught C while studying in the university but that was
10 years ago and I've only picked up programming again in the past two
or three. I understand digital hardware and the core C concepts,
however, I don't have the opportunity to work alongside an experienced
colleague to learn how I should write my code to be up to "industry
standards" (= not be an unmaintainable mess etc) and I'm looking for
something to refer to, other than my own trial and error.
Example topics include anything from structuring headers to using
globals or structuring function calls- especially under the prism of
embedded applications. I would appreciate any suggestions on online
resources or books.
Regards,
Spiros
_______________________________________________
Synth-diy mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Synth-diy@synth-diy.org">Synth-diy@synth-diy.org</a>
<a class="moz-txt-link-freetext" href="http://synth-diy.org/mailman/listinfo/synth-diy">http://synth-diy.org/mailman/listinfo/synth-diy</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Synth-diy mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Synth-diy@synth-diy.org">Synth-diy@synth-diy.org</a>
<a class="moz-txt-link-freetext" href="http://synth-diy.org/mailman/listinfo/synth-diy">http://synth-diy.org/mailman/listinfo/synth-diy</a>
?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
-- ScottG
________________________________________________________________________
-- Scott Gravenhorst
-- <a class="moz-txt-link-freetext" href="http://scott.joviansynth.com/">http://scott.joviansynth.com/</a>
-- When the going gets tough, the tough use the command line.
-- Matt 21:22
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Synth-diy mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Synth-diy@synth-diy.org">Synth-diy@synth-diy.org</a>
<a class="moz-txt-link-freetext" href="http://synth-diy.org/mailman/listinfo/synth-diy">http://synth-diy.org/mailman/listinfo/synth-diy</a>
</pre>
</blockquote>
</body>
</html>