-1

I wrote some code in the past for 8bit MCUs, realizing that every time I gained experience, the next iteration will be with a wrapper API or something more distant from the "bare metal" register access. I also end up a bit in working environments, learning the company philosophy behind a certain code style.

But I saw work environments with nice ordered code, due to code management, readability and the like and so all the good things that came from that. Which make sense from my experience.

Then I saw code from other companies, which is showing a not so nice looking already in the main file, with direct register access and not very standard functions, at least for the low level drivers and IO inits.

I personally tend to wrap as much as possible, because in the end once it is done, the code is really simple to read, maintain and making it portable. And also the stack is not an issue, due to the nature of the low level driver. This can also easily integrated with the application code, while keeping readability, maintainability and portability. All -ility. I also learned how important is, for the -ility reasons, having a library and its HAL layer.

The question is: why someone should be tidy in code writing if in the final product no one will check your code as long it comply the functional requirements? Are there opinions or reasons with or against being tidy? I am talking about reliable code environments, but with no particular process to follow (like no MISRA-C, DO-178B and neither ISO-26262 and the like).

thexeno
  • 109
  • 4

2 Answers2

3

Lower defect rate and faster time to market are usually more important than perfect hardware utilization.

Tidy, easy-to-read code is usually easier to write and update, and needs less debugging. It may be slightly less efficient (more indirection), but hardware is cheap and programmers' time is not.

One important exception is performance-critical code, where you may need to go out of your way to squeeze the last bits of performance from the available hardware. Here one should remember that no optimization is possible before profiling, and the critical path is usually a small part of the whole codebase.

So, a tidier codebase is better as long as it does not tax the critical path. But this is not a function of tidiness, it's a function of a correct design.

9000
  • 24,162
  • 4
  • 51
  • 79
1

Well/poor designed code is totally a matter of maintenance for you and your company and not of functionality for the customer although the software might deteriorate into non-functional bunch of bugs (worst case).

There're two extremes. One is absolutely no design and pure spaghetti code and the other is every bit is designed and you never finish the software because it's still not perfect. I've seen both and the truth lies in between. You trade of one or the other to progress at the fastest pace you can.

When maintenance starts to go up, tidy up but start with the simplest solution you can come up with to make it work at the beginning.

Martin Fowler wrote a great article about this topic. You need to calibrate the break-even point for yourself where design pays off but it's usually earlier than you think. I've worked with a bunch of no-design source code and wrapped this experience into a little story.

Ewald B.
  • 219
  • 1
  • 4