| Electronics > Projects, Designs, and Technical Stuff |
| uSupply Firmware Released |
| << < (6/11) > >> |
| Jeroen3:
--- Quote from: uer166 on May 26, 2020, 11:53:46 pm ---Even in the tiny forum window I can figure out what's going on.. This must be hardware vs. software engineering thinking ways. --- End quote --- Script hackers vs SOLID developers. https://nl.wikipedia.org/wiki/SOLID |
| SiliconWizard:
--- Quote from: EEVblog on May 27, 2020, 04:47:25 am --- --- Quote from: nuclearcat on May 27, 2020, 01:05:10 am ---Anonymous function (refered as authored by klingon) probably overkill for embedded and exactly opposite "of easy to understand code". And whole fact returning pointer to *char by anonymous function might be fine on PC, but ehm, i think questionable in embedded. But thats IMHO, i might be wrong. I generally try to be careful and conservative with C++ features in embedded, you never know which function will make your code "suddenly overweight" or will start using "under the hood" dynamic memory allocation/reentrant functions/etc and guarantee you problems. But it’s best to prove that, if i can write better code. Sure if i will be alive by the time uSupply will be released for sales. --- End quote --- The other thing is that David kept finding issues in the C++ compiler (and STM target), as in bugs or quirks that prevented the program from working, and in one case resulted in weeks worth of project delay until the compiler could be patched. --- End quote --- That's one more reason the choice of using C++ in this project, at least the way Dave used it, was probably not a good idea. Days of delay for tools issues - that's OK. But weeks? You were probably not in a big hurry at the time, and wanted to give him maximum autonomy, but as a manager, you should probably have made a couple decisions to limit useless delays. Again, I admire the clarity and elegance of his code, but I still question the choices and architecture. A bit too bloated for my taste. Now to be clear, OTOH I find Dave (Jones) coding style pragmatic, but a bit too simplistic and not the most reusable or most easy to maintain. My take would be somewhere in between. |
| nuclearcat:
--- Quote from: SiliconWizard on May 27, 2020, 02:01:41 pm ---Now to be clear, OTOH I find Dave (Jones) coding style pragmatic, but a bit too simplistic and not the most reusable or most easy to maintain. My take would be somewhere in between. --- End quote --- For me it is pretty typical AVR Studio code, "It just works(tm)", similar to code in Atmel datasheets. (And half of code is unavoidable registers voodoo). |
| MiroS:
--- Quote from: Dave on May 27, 2020, 12:53:04 am ---As soon as software becomes slightly more complex, you need to start splitting it in logical units, which you put into separate files. A well written software should not have files that stretch for more than a couple of hundred lines. There are of course always exceptions to this rule, but in general, one shouldn't have to scroll around and search for a particular part of code. --- End quote --- If you think than please take this as home assigement https://ptolemy.berkeley.edu/projects/embedded/pubs/downloads/spice/spice2.ibm.tar.gz and come back where is more clarity and complexity :popcorn: |
| Dave:
--- Quote from: nuclearcat on May 27, 2020, 01:05:10 am ---Anonymous function (refered as authored by klingon) probably overkill for embedded and exactly opposite "of easy to understand code". And whole fact returning pointer to *char by anonymous function might be fine on PC, but ehm, i think questionable in embedded. But thats IMHO, i might be wrong. I generally try to be careful and conservative with C++ features in embedded, you never know which function will make your code "suddenly overweight" or will start using "under the hood" dynamic memory allocation/reentrant functions/etc and guarantee you problems. --- End quote --- There are some aspects of C++ that I think would be useful for embedded platforms, like operator overloading, constructors and destructors, default arguments in functions. Other than that... :-// I'm not terribly fond of anonymous functions, either. --- Quote from: MiroS on May 27, 2020, 06:55:29 pm ---If you think than please take this as home assigement https://ptolemy.berkeley.edu/projects/embedded/pubs/downloads/spice/spice2.ibm.tar.gz and come back where is more clarity and complexity :popcorn: --- End quote --- You linked in an ancient project coded in FORTRAN (I only know this because I actually searched for the SPICE wiki). I can't possibly comment on a programming language which I don't know and have never used. If the language does allow for splitting the code into multiple files, then 18k lines in a single file is in fact terrible coding practice. |
| Navigation |
| Message Index |
| Next page |
| Previous page |