Ah, seeing people posting coding styles, and other people debating them, I know my life is too short to join this conversation.
C Style: My favorite C programming practices (2014)
121–130 of 139 posts
Re: C Style: My favorite C programming practices (2014)
#122Earlier quoted context omitted.
This is probably a snarky reply, but here is the serious answer: proportional fonts, with appropriate kerning, is a lot more legible than monospaced font. There is a reason why the press moved into that direction once it was technically feasible. But the same people that bring books as an example why 80 character line length should be enforced would gag at the notion of using proportional fonts for development. It ju…
Code uses much more punctuation than prose, and punctuation is hard to discern in a proportional font.
Depends on which language you are writing in. Historically Smalltalk UIs use proportional fonts, and they work just fine.
Re: C Style: My favorite C programming practices (2014)
#123Tabs vs Spaces Tabs are always correct, IF spaces are never used instead. One tab, for one level of indent. Adjust to preference. Alas, I don't think there's a standard way of specifying... // kate: space-indent off; indent-width 8; tab-width 8; mixedindent off; indent-mode tab; Similarly, // comments should be preferred, but /* comments */ are acceptable at the top of large function blocks for large blobs of comment…
There is always .editorconfig [1] to setup indent if you have a directory of files. In places where it really matters (Python) I'll always comment with what I've used.
Re: C Style: My favorite C programming practices (2014)
#124> 80-characters-per-line is a de-facto standard for viewing code. Readers of your code who rely on that standard, and have their terminal or editor sized to 80 characters wide, can fit more on the screen by placing windows side-by-side. This is one of the silliest practices to still be enforced or even considered in 2024. “Readers” should get a modern IDE/text editor and/or modern hardware.
As soon as you collaborate with more people, 80 charactars becomes a valid target for line width. Eventually you'll have someone reading your code in a manner that is hardly pleasant with lengths of 200 characters or more:
- Someone using a Braille display
- Someone with a vision impairment (i.e. high scaling factor; common occurence during ageing)
- A group of people that doesn't sit close to the display
- Someone with a low-DPI (or small) display due to the normal workplace being unavailable
Re: C Style: My favorite C programming practices (2014)
#125i was sort of hoping for something like https://nullprogram.com/blog/2023/10/08/, which shows a bunch of inventions that simplify your programming. some of them may be more trouble than they're worth, but they're at least novel and interesting
by contrast, this document is largely motherhood and apple pie — and where it isn't (e.g., when it advocates titlecasing struct types or never typedeffing primitive types), i often think it's wrong. 'Write assertions to meaningfully crash your program before it does something stupid, ... to prevent a security vulnerability' is especially wrong; one of the major features of the standard assert() macro is that it's turned off in release builds!
the named-arguments macro hack is an example of the kind of thing i was most hoping to find in here
if you write something like this, don't dilute whatever value it may have with your opinions about tabs vs. spaces, line length, what natural language to write your comments and identifiers in, include guards, how many blank lines to put between functions, etc. these have been debated to death, and you're unlikely to have any brilliant insights about them that other people will be happy to have read
Re: C Style: My favorite C programming practices (2014)
#126> Write correct, readable, simple and maintainable software, and tune it when you're done, with benchmarks to identify the choke points If speed is a primary concern, you can't tack it on at the end, it needs to be built in architecturally. Benchmarks applied after meeting goals of read/maintainability are only benchmarking the limits of that approach and focus. They can't capture the results of trying and benchmarki…
I don't know if this embedded development still alive. I'm writing firmware for nRF BLE chip which is supposed to run from battery and their SDK uses operating system. Absolutely monstrous chips with enormous RAM and Flash. Makes zero sense to optimize for anything, as long as device sleeps well.
i just learned the other day that you can get a computer for 1.58¢ in quantity 20000: https://jlcpcb.com/partdetail/NyquestTech-NY8A051H/C5143390
if we can believe the datasheet, it's basically a pic12f clone (with 55 'powerful' instructions, most single-cycle) with 512 instructions of memory, a 4-level hardware stack, and 32 bytes of ram, with an internal 20 megahertz clock, 20 milliamps per pin at 5 volts, burning half a microamp in halt mode and 700 microamps at full speed at 3 volts
and it costs less than most discrete transistors. in fact, although that page is the sop-8 version, you can get it in a sot23-6 package too
there are definitely a lot of things you can do with this chip if you're willing to optimize your code. but you aren't going to start with a 30-kilobyte firmware image and optimize it until it fits
yeah it's not an nrf52840 and you probably can't do ble on it. but the ny8a051h costs 1.58¢, and an nrf52840 costs 245¢, 154 times as much, and only runs three times as fast on the kinds of things you'd mostly use the ny8a051h for. it does have a lot more than 154 times as much ram tho
for 11.83¢ you can get a ch32v003 https://www.lcsc.com/product-detail/Microcontroller-Units-MC... which is a 48 megahertz risc-v processor with 2 kilobytes of ram, 16 kilobytes of flash, a 10-bit 1.7 megahertz adc, and an on-chip op-amp. so for 5% of the cost of the nrf52840 you get 50% of the cpu speed, 1.6% of the ram, and 0% of the bluetooth
for 70¢, less than a third the price of the nrf52840, you can get an ice40ul-640 https://www.lcsc.com/product-detail/Programmable-Logic-Devic... which i'm pretty sure can do bluetooth. though it might be saner to hook it up to one of the microcontrollers mentioned above (or maybe something with a few more pins), you can probably fit olof kindgren's serv implementation of risc-v https://github.com/olofk/serv into about a third of it and probably get over a mips out of it. but the total amount of block ram is 7 kilobytes. the compensating virtue is that you have another 400 or so luts and flip-flops to do certain kinds of data processing a lot faster and more predictably than a cpu can. 19 billion bit operations per second and pin-to-pin latency of 9 nanoseconds
so my summary is that there's a lot of that kind of embedded work going on, maybe more than ever, and you can do things today that were impossible only a few years ago
Re: C Style: My favorite C programming practices (2014)
#127Earlier quoted context omitted.
I'm not sure what you have in mind, but in my mind the mechanical enforcement really means something like clang-format [1] and that surely works. [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html#use...
Have you actually tried? Personally I have evaluated and then abandonded clang-format (for reasons including but not limited to the interplay between macros and indentation), and most tool's support for tab-indentation + space-alignments is flaky to non-existent. I wouldn't want to constrain my setup to one that integrates clang-format just for a needlessly complicated requirement when I could just abandon tabs altog…
If you want to keep space alignments that's honestly to be expected. Exclusively using tabs would work much better, partly for the reason you have said. On the requirement of clang-format itself though... Yeah, that is more like a problem of C and its ecosystem indeed.
Re: C Style: My favorite C programming practices (2014)
#128Earlier quoted context omitted.
This is probably a snarky reply, but here is the serious answer: proportional fonts, with appropriate kerning, is a lot more legible than monospaced font. There is a reason why the press moved into that direction once it was technically feasible. But the same people that bring books as an example why 80 character line length should be enforced would gag at the notion of using proportional fonts for development. It ju…
I'm glad you cleared this all up for us. Other people disagree with you and it's best to not assume they are idiots.
So far, you are the only one making a fool of themselves.
Re: C Style: My favorite C programming practices (2014)
#129I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well. One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise". As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in…
funnily the example used, i.e `printf` of single values is very special. Under the hood, variadic arguments that are `single` are actually converted to `double`. See the `cvtss2sd` in [1].
Re: C Style: My favorite C programming practices (2014)
#130I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well. One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise". As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in…
Yeah, sometimes as a graphics programmer you don't even want the precision provided by built-in functions! As it has been pointed out though, be careful about error propagation