Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
user:embedded_c_code_doesn_t_have_to_be_ugly [2020/05/11 18:47] – [6. Code blocks' nesting] Igor Yefmov | user:embedded_c_code_doesn_t_have_to_be_ugly [2020/05/11 18:59] – [3. #define (and const) vs. enum] Igor Yefmov | ||
---|---|---|---|
Line 69: | Line 69: | ||
As such (barring external dependencies) I always advise on using the latest stable language standard supported by the toolchain that your organization is comfortable with. And yes, that means that engineers must continually improve their grasp of the language and be on top of the latest stable standard to efficiently take advantage of the improvements provided by that standard. | As such (barring external dependencies) I always advise on using the latest stable language standard supported by the toolchain that your organization is comfortable with. And yes, that means that engineers must continually improve their grasp of the language and be on top of the latest stable standard to efficiently take advantage of the improvements provided by that standard. | ||
- | ==== 3. #define (and const) vs. enum ==== | + | ==== 3. #define (and const) vs. enum and magic numbers |
So much has been said about the many advantages of pushing as much work as possible away from the preprocessor and into the compiler that is amazes me to still see tons of ''# | So much has been said about the many advantages of pushing as much work as possible away from the preprocessor and into the compiler that is amazes me to still see tons of ''# | ||
Line 96: | Line 96: | ||
<code C>enum{ s2r_uvc_stream_buf_size = s2r_ep_bulk_video_pkts_count * s2r_ep_bulk_video_pkt_size };</ | <code C>enum{ s2r_uvc_stream_buf_size = s2r_ep_bulk_video_pkts_count * s2r_ep_bulk_video_pkt_size };</ | ||
+ | |||
+ | === Magic numbers === | ||
+ | You know, that kind: | ||
+ | <code C> | ||
+ | |||
+ | Compare that to this code and tell me - which one makes you understand what that code does? | ||
+ | <code C> | ||
==== 4. Bit manipulations vs. structured data ==== | ==== 4. Bit manipulations vs. structured data ==== | ||
Line 267: | Line 274: | ||
Speaking of stack depth: partitioning your code into smaller functions may indeed //reduce// your stack requirement as you won't be needing to allocate every-single-variable-ever-used-in-any-branch in one chunk, but instead only use up as much stack as needed for each individual function. | Speaking of stack depth: partitioning your code into smaller functions may indeed //reduce// your stack requirement as you won't be needing to allocate every-single-variable-ever-used-in-any-branch in one chunk, but instead only use up as much stack as needed for each individual function. | ||
==== 7. Code comments ==== | ==== 7. Code comments ==== | ||
+ | <code C> | ||
+ | |||
+ | int i = 1; // set i to 1 | ||
+ | |||
+ | i++; // increment i by 1</ | ||
+ | The comments above are utterly useless. Not only they don't anything to what is already expressed in the code((which is bad enough on its own)), there' |