Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Style: My favorite C programming practices (2014)

github.com

Post reply on HN
Print view View original

131–139 of 139 posts

Re: C Style: My favorite C programming practices (2014)

#131

Post by daelon »

kragen wrote: post #126
vbezhenar wrote: post #32

Earlier quoted context omitted.

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…

Just to be pedantic, if it's a clone of the 8 bit PICs, then one instruction takes 4 clock cycles, so a 20MHz clock should be considered 5MHz if you're trying to compare operations per second.

Re: C Style: My favorite C programming practices (2014)

#132

Post by ____________g »

xigoi wrote: post #111
LeoNatan25 wrote: post #66

Earlier 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.

I agree. I've tried coding in C-like languages with proportional fonts a few times, and punctuation ends up feeling cramped, hurting legibility. We need more proportional fonts for programming where punctuation gets the same size and spacing as in monospaced fonts.

Re: C Style: My favorite C programming practices (2014)

#133

Post by kragen »

daelon wrote: post #131
kragen wrote: post #126

Earlier quoted context omitted.

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…

Just to be pedantic, if it's a clone of the 8 bit PICs, then one instruction takes 4 clock cycles, so a 20MHz clock should be considered 5MHz if you're trying to compare operations per second.

that's a good point! i wondered about that, but i don't have the chip yet, so i checked the datasheet. the datasheet lists a cycle count for each instruction, and as i said, most instructions are 1 cycle

on the other hand, something like a 32-bit multiplication or a floating-point subtraction is going to cost a lot of instructions, if you can afford it at all

Re: C Style: My favorite C programming practices (2014)

#134

Post by ragnese »

eschneider wrote: post #112
ragnese wrote: post #108

Earlier quoted context omitted.

The problem with all of these rules of thumb is that they're vague to the point of being vacuously true. Of course we all agree that "premature optimization is the root of all evil" as Knuth once said, but the saying itself is basically a tautology: if something is "premature", that already means it's wrong to do it. I'll be more impressed when I see specific advice about what kinds of "optimizations" are premature.…

Ok, a bit more detail then. :) Architecting for performance means picking your data structures, data flow, and algorithms with some thought towards efficiency for the application you have in mind. Details will vary a lot depending on context. But as many folks have said, this sort of thing can't be done after the fact. As for "doing something dumb", I've often seem fellow engineers do things like repeatedly insert in…

> As for "doing something dumb", I've often seem fellow engineers do things like repeatedly insert into sorted data structures in a loop instead of just inserting into an unsorted structure and then sorting after the inserts. If you think about it for just a minute, it should be obvious why that's not smart (for most cases.) Stuff like that.

That's a great example that I've seen in the wild as well!

> Nobody's saying to pick suboptimal solutions at all.

No, I realize that. And most of my comment wasn't intended as some kind of direct disagreement to yours. It was mostly just some observations. One of which is that advice about writing efficient code is usually too vague to be useful, and the other is that people take the "don't optimize without measuring" advice to mean something ridiculous in the opposite extreme that reads more like "just write whatever garbage looks pretty to you because any forethought about what makes sense to the computer is premature optimization". I wasn't trying to say that's what you were advocating for, though.

Re: C Style: My favorite C programming practices (2014)

#135

Post by nwellnhof »

gavinhoward wrote: post #99
nwellnhof wrote: post #87

Earlier quoted context omitted.

In the vast majority of cases, integer overflow or truncation when casting is a bug, regardless whether it is undefined, implementation-defined or well-defined behavior. Avoiding undefined behavior doesn't buy you anything. If you start to fuzz test with UBSan and -fsanitize=integer, you will realize that the choice of integer types doesn't matter much. Unsigned types have the benefit that overflowing the left end of…

> Avoiding undefined behavior doesn't buy you anything. This is absolutely false. Say you want to check if a mathematical operation will overflow. How do you do it with signed types? Answer: you can't. The compiler will delete any form of check you make because it's UB. (There might be really clever forms that avoid UB, but I haven't found them.) The problem with UB isn't UB, it's the compiler. If the compilers didn'…

> You can't do that with signed types.

What? Of course you can. If you want to add ints a and b:

    if (b >= 0 ? a > INT_MAX - b : a

Re: C Style: My favorite C programming practices (2014)

#136

Post by Delk »

lifthrasiir wrote: post #28

While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a good point to start the discussion regardless of my own opinion. Thus I'll contribute back by giving my own judgement for every single item here: Absolute agreement * Always develop and compile with all warnings (and more) on * #include the definition of ever…

> * Program in American English [only applicable for native speakers]

I don't really care that much about American vs. British English, except that it should be consistent within the code base. But I do think programming in English is generally a best practice that applies even if you aren't a native speaker.

I agree with most of your (dis)agreements, though.

Re: C Style: My favorite C programming practices (2014)

#137

Post by gavinhoward »

nwellnhof wrote: post #135
gavinhoward wrote: post #99

Earlier quoted context omitted.

> Avoiding undefined behavior doesn't buy you anything. This is absolutely false. Say you want to check if a mathematical operation will overflow. How do you do it with signed types? Answer: you can't. The compiler will delete any form of check you make because it's UB. (There might be really clever forms that avoid UB, but I haven't found them.) The problem with UB isn't UB, it's the compiler. If the compilers didn'…

> You can't do that with signed types. What? Of course you can. If you want to add ints a and b: if (b >= 0 ? a > INT_MAX - b : a

Okay, that's addition.

Now do it for multiplication.

Re: C Style: My favorite C programming practices (2014)

#138

Post by lifthrasiir »

Delk wrote: post #136
lifthrasiir wrote: post #28

While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a good point to start the discussion regardless of my own opinion. Thus I'll contribute back by giving my own judgement for every single item here: Absolute agreement * Always develop and compile with all warnings (and more) on * #include the definition of ever…

> * Program in American English [only applicable for native speakers] I don't really care that much about American vs. British English, except that it should be consistent within the code base. But I do think programming in English is generally a best practice that applies even if you aren't a native speaker. I agree with most of your (dis)agreements, though.

Yeah, that was what I meant (mea culpa). I often appreciate the use of native languages when all members are expected to understand that, but a public code base would have to be written in English. The exact dialect of English is not as important.

Re: C Style: My favorite C programming practices (2014)

#139

Post by naasking »

janice1999 wrote: post #74
lifthrasiir wrote: post #28

While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a good point to start the discussion regardless of my own opinion. Thus I'll contribute back by giving my own judgement for every single item here: Absolute agreement * Always develop and compile with all warnings (and more) on * #include the definition of ever…

> * No global or static variables if you can help it (you probably can) I can't imagine doing this on embedded systems.

I think it's better understood as, "global and static state should only be declared by the client". So all of your functions should take pointers and all of your data should preferably be declared as types, and the points of your program that consume your code can declare their lifetime.

So if you're inclined to declare 2 global variables, instead define a struct with those two values and your functions take a pointer to that struct, and whatever code calls into yours can then decide whether they want to define that struct as having global scope. It just makes for more modular code.

Post reply on HN