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'm definitely a big fan of readability in code. Of course you have to know your intended audience. People reading kernel code are not the same audience as, I don't know, people writing a financial application in a high level language.
With the work I do I am able to favour readability over efficiency (then optimize if required.. no premature optimization). It makes maintenance so much easier (and let's face it, code spends most of its life being maintained). Code is already way harder to read than write a
I never said Linus was wrong. In fact I was agreeing it is correct in the kernel. A kernel dev would have no problem reading and understanding his example. Your average joe coder might stumble over it.
This is simply a smaller-scale of the same kind of improvement that object-oriented is.
What? That doesn't make any sense in the context of replying to my comment.
I never said Linus was wrong. In fact I was agreeing it is correct in the kernel. A kernel dev would have no problem reading and understanding his example. Your average joe coder might stumble over it.
Average Joe coder must be educated, not kept in the darkness.
Average Joe coder must be educated, not kept in the darkness.
No. Not really.
Not all developers need to be able to read advanced pointer usage and tricks for the sake of tricks is stupid. There must be a measurable performance difference or it has to be easily readable by the group developing. If it isn't easily readable and there is no performance justification then education isn't the issue, it's developer ego, "Well I can read it."
Yeah, good for you. But I don't care about that. I care about whoever ends up having to maintain your difficult to read code. Prematurely optimize code, and even with ok comments I guarantee it's going to take longer to maintain (even for the original developer). Clear and concise is the way to go except in pure performance based applications (such as an OS kernel, embedded device etc). And even in those applications you only cross the line from clear and concise when necessary. In high level code you should always go simple until it's proven a simple solution won't work. That also goes for architecture. Simpler the better.
As a musician I see this all the time. Complexity for the sake of being complex. It's just musician ego. The best musicians have tons of technical ability, but apply it tastefully (not having to show it off at every possible opportunity).
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:2)
With the work I do I am able to favour readability over efficiency (then optimize if required.. no premature optimization). It makes maintenance so much easier (and let's face it, code spends most of its life being maintained). Code is already way harder to read than write a
Re: (Score:0)
Sorry, but I think Linus is right here. This is simply a smaller-scale of the same kind of improvement that object-oriented is.
Re: (Score:2)
Sorry, but I think Linus is right here.
I never said Linus was wrong. In fact I was agreeing it is correct in the kernel. A kernel dev would have no problem reading and understanding his example. Your average joe coder might stumble over it.
This is simply a smaller-scale of the same kind of improvement that object-oriented is.
What? That doesn't make any sense in the context of replying to my comment.
Re: (Score:0)
I never said Linus was wrong. In fact I was agreeing it is correct in the kernel. A kernel dev would have no problem reading and understanding his example. Your average joe coder might stumble over it.
Average Joe coder must be educated, not kept in the darkness.
Re:Not So Fast On The Pointers (Score:2)
Average Joe coder must be educated, not kept in the darkness.
No. Not really.
Not all developers need to be able to read advanced pointer usage and tricks for the sake of tricks is stupid. There must be a measurable performance difference or it has to be easily readable by the group developing. If it isn't easily readable and there is no performance justification then education isn't the issue, it's developer ego, "Well I can read it."
Yeah, good for you. But I don't care about that. I care about whoever ends up having to maintain your difficult to read code. Prematurely optimize code, and even with ok comments I guarantee it's going to take longer to maintain (even for the original developer). Clear and concise is the way to go except in pure performance based applications (such as an OS kernel, embedded device etc). And even in those applications you only cross the line from clear and concise when necessary. In high level code you should always go simple until it's proven a simple solution won't work. That also goes for architecture. Simpler the better.
As a musician I see this all the time. Complexity for the sake of being complex. It's just musician ego. The best musicians have tons of technical ability, but apply it tastefully (not having to show it off at every possible opportunity).