Prusa-firmware: Arduino IDE 1.8.5 warnings during compiling MK3 with Compiler warnings set to "More"
Compiling the MK3 firmware having Compiler warnings set to "More" shows a lot of warnings.
Remembering from the MK2 branch it had these in the beginning too and have been cleaned up bit later. Lot have been done by @thess. Thanks again for that.
Hope as soon Prusa got all issues/bugs/improvements done they cleanup these warnings.
@PavelSindler @XPila @bubnikv Please let us know if you need help with that and if pull requests from us makes sense at this moment.
3d-gussner
All 4 comments
I'm not really apologizing for the following rant, however I feel strongly about such issues...
Cleaning up code warnings is kind of like weeding a garden. In this case, the garden is almost overgrown with weeds. During my effort to make "clean" source out of the Prusa firmware (MK2 branch), quite a few errors in coding (uninitialized variables, unused variables, code which did nothing, array overruns, etc) were uncovered. Some of which were amusing bugs. Most of this detritus has been faithfully carried over to the MK3 branch with no regard to cleanliness or ease of maintenance. On top of that, the habit of commenting out code rather than deleting it, meaningless conditionals which do not compile, and bad indentation practices leads to making these efforts even harder than they need to be.
I believe that Prusa Research is not at all interested in the quality of their code. Witness similar attempts by a contributor to Slic3r back in September who tried to cleanup those sources. Proposals for better build instructions, Travis integration, etc. have also been ignored. As a counter example, take a look at the current Marlin 2.0 branch and admire what could be here - if only...
As long as the software side of Prusa Research remains as it is, us professionals (I have been in the computer industry for nearly 50yrs) can only shrug and hope for the best. Hey, it works (mostly)! It is bloated, overgrown and slightly out-of-control. Balancing "functionality, quality, time-to-market (cost)" is never easy, but picking only 2 and ignoring the 3rd (quality in this case) is not the best choice.
PS - I really love my Prusa printer, the hardware and documentation is spot on.
thess
on 24 Jan 2018
I think it is more a case of being too busy moving forward, to caring for cleaning up.
GurliGebis
on 25 Jan 2018
@XPila Why adding another MK25 branch?
I have a feeling that it will generate again problems that pull requests/fixes etc. will be forgotten and not implemented. Maintenance gets worse over time as you have to watch all 3 branches.
I like that you use a lot of #ifdef functions to separate the MK3 features from the MK25.
But as the MK3 and now also the MK25 miss lot of MK2 branch fixes and features it will be a step back for MK2/s users updating to MK25.
Wouldn't i make sens to rename this to MK (master) or so and consolidate the MK3 and MK2 branches?
3d-gussner
on 2 Feb 2018
Outdated, so i close it
3d-gussner
on 8 Jan 2019
Related issues
KarlZeilhofer
路
4Comments
erikcramerjr
路
4Comments
NoNme1
路
4Comments
duartemv
路
5Comments
3d-gussner
路
4Comments
Most helpful comment
I'm not really apologizing for the following rant, however I feel strongly about such issues...
Cleaning up code warnings is kind of like weeding a garden. In this case, the garden is almost overgrown with weeds. During my effort to make "clean" source out of the Prusa firmware (MK2 branch), quite a few errors in coding (uninitialized variables, unused variables, code which did nothing, array overruns, etc) were uncovered. Some of which were amusing bugs. Most of this detritus has been faithfully carried over to the MK3 branch with no regard to cleanliness or ease of maintenance. On top of that, the habit of commenting out code rather than deleting it, meaningless conditionals which do not compile, and bad indentation practices leads to making these efforts even harder than they need to be.
I believe that Prusa Research is not at all interested in the quality of their code. Witness similar attempts by a contributor to Slic3r back in September who tried to cleanup those sources. Proposals for better build instructions, Travis integration, etc. have also been ignored. As a counter example, take a look at the current Marlin 2.0 branch and admire what could be here - if only...
As long as the software side of Prusa Research remains as it is, us professionals (I have been in the computer industry for nearly 50yrs) can only shrug and hope for the best. Hey, it works (mostly)! It is bloated, overgrown and slightly out-of-control. Balancing "functionality, quality, time-to-market (cost)" is never easy, but picking only 2 and ignoring the 3rd (quality in this case) is not the best choice.
PS - I really love my Prusa printer, the hardware and documentation is spot on.