simply good use of pointers-to-pointers etc. For example, I've seen too many people who delete a singly-linked list entry by keeping track of the "prev" entry, and then to delete the entry, doing something like
if (prev) prev->next = entry->next; else list_head = entry->next;
and whenever I see code like that, I just go "This person doesn't understand pointers". And it's sadly quite common.
People who understand pointers just use a "pointer to the entry pointer", and initialize that with the address of the list_head. And then as they traverse the list, they can remove the entry without using any conditionals, by just doing a "*pp = entry->next".
I'm going to have to disgree with Linus on that one. When I'm coding in a mixed group of people that includes old farts and interns and the performance isn't that critical, I'll do the former over the latter to insure that everyone in the group will understand it easily and will have less chance of breaking it if they change it. It can mean the difference between code that is robust and code that is fragile when it's being worked on, not just when it's running.
I believe that his pointer example is more a matter of personal style. I can easily see how doing away with the conditions will make for more efficient code, but in many cases, the preference he cites might also make the code a little more obfuscated. However, even that's nothing that a single-line comment wouldn't fix, making sure that whoever is reading the code fully realizes the intent behind it. I think perfectly valid arguments can be made for doing it either way.
I actually find his pointer version more readable. It doesn't introduce a "false branch", and anyone fairly comfortable with C (working on the Linux kernel, say) should be able to understand that sort of code.
I've been programming in C for nearly 30 years... when I saw his counter-example, I still had to pause for just a second to think about it. Yes, I see what he did, and I've even used that pattern myself in software that I've written. There are quite legitimate reasons to use that form that are applicable to system programming, so I don't object to it over the conditional form (I actually even prefer it, in many cases), but a simple one-line comment which clarifies the intent would definitely be preferred.
The only assumption that you should be making about people who might have to maintain your code in the future, unless this is a personal project that nobody else is ever going to see, is that they are not going to be thinking exactly like you. Just because the maintainer of the code might be expected to have a certain level of competence doesn't mean that he or she will be familiar with every single idiom that you use. Clarity is paramount.
Not So Fast On The Pointers (Score:4, Interesting)
simply good use of pointers-to-pointers etc. For example, I've seen too many people who delete a singly-linked list entry by keeping track of the "prev" entry, and then to delete the entry, doing something like
if (prev)
prev->next = entry->next;
else
list_head = entry->next;
and whenever I see code like that, I just go "This person doesn't understand pointers". And it's sadly quite common.
People who understand pointers just use a "pointer to the entry pointer", and initialize that with the address of the list_head. And then as they traverse the list, they can remove the entry without using any conditionals, by just doing a "*pp = entry->next".
I'm going to have to disgree with Linus on that one. When I'm coding in a mixed group of people that includes old farts and interns and the performance isn't that critical, I'll do the former over the latter to insure that everyone in the group will understand it easily and will have less chance of breaking it if they change it. It can mean the difference between code that is robust and code that is fragile when it's being worked on, not just when it's running.
Re: (Score:5, Interesting)
I believe that his pointer example is more a matter of personal style. I can easily see how doing away with the conditions will make for more efficient code, but in many cases, the preference he cites might also make the code a little more obfuscated. However, even that's nothing that a single-line comment wouldn't fix, making sure that whoever is reading the code fully realizes the intent behind it. I think perfectly valid arguments can be made for doing it either way.
Personally, I would classify thi
Re: (Score:0)
I actually find his pointer version more readable. It doesn't introduce a "false branch", and anyone fairly comfortable with C (working on the Linux kernel, say) should be able to understand that sort of code.
Re:Not So Fast On The Pointers (Score:3)
I've been programming in C for nearly 30 years... when I saw his counter-example, I still had to pause for just a second to think about it. Yes, I see what he did, and I've even used that pattern myself in software that I've written. There are quite legitimate reasons to use that form that are applicable to system programming, so I don't object to it over the conditional form (I actually even prefer it, in many cases), but a simple one-line comment which clarifies the intent would definitely be preferred.
The only assumption that you should be making about people who might have to maintain your code in the future, unless this is a personal project that nobody else is ever going to see, is that they are not going to be thinking exactly like you. Just because the maintainer of the code might be expected to have a certain level of competence doesn't mean that he or she will be familiar with every single idiom that you use. Clarity is paramount.