4 ms·

If you understood pointers well enough, you would see Linus's version as more readable. I agree - and as someone who makes his living as a C programmer, I'm su

by mtoddh 14y ago

If you understood pointers well enough, you would see Linus's version as more readable. I agree - and as someone who makes his living as a C programmer, I'm sure someone could easily come up with a terse piece of Ruby code that I would view as too clever, and therefore confusing, but which the vast majority of programmers on here would look at and think, "a beginner may be confused by this, but a competent Ruby programmer would not be." I know some of this comes down to stylistic preferences, and likely some have had bad experiences maintaining code that went overboard with this sort of thing. But I also think that if these snippets of code were being discussed in a forum with a bias towards low-level development, rather than HN, which seems biased towards web development, you'd be seeing some very different responses.

muyuu 14y ago
That's the Perl school of thought that basically finished Perl as a language for big projects. Personally, I have 20 years of C programming experience and I prefer to avoid clever tricks when they add no effective advantage. Making code shorter is not the end-all of programming. Code is written for people to understand rather than for computers to execute (quoting Sussman). It's fine to strive for efficiency since we're talking about OS development here, but it's not the case in this bit of code really, is it? What is more likely to confuse a maintainer, an extra level of indirection or an extra trivial "if"? However if you are committed to do all the maintenance yourself, then you can pick as you wish.
- mtoddh 14y ago
  That's the Perl school of thought that basically finished Perl as a language for big projects. It's a great point, and I hated Perl for this very reason. And I'm sure some of it is my defensiveness since this is how I program. But some of it is also my concern that it might signal, during an interview say, that the candidate might not really have a good grasp of pointers. For instance, given the following snippet of code, candidates that didn't really seem to grok pointers wouldn't see that the append() function could not be modifying the list in main(): struct node { int val; struct node *next; }; static void append(struct node *list, int val); int main(int argc, char **argv) { struct node *list = NULL; append(list, 4); ... } And my preference for fixing such an implementation would be to change append to take a pointer-to-a-pointer: static void append(struct node **list, int val); with an implementation like: static void append(struct node **list, int val) { struct node **ppn, *pn; if ( (pn = malloc(sizeof *pn)) == NULL) { perror("malloc"); exit(1); } pn->val = val; pn->next = NULL; for (ppn = list; *ppn; ppn = &(*ppn)->next) /* find tail */; *ppn = pn; } and update the call in main() to append(&list, 4). But as I said, you make a good point, and I agree that your method is the safer of the two options from a maintainability point of view.

by mtoddh 14y ago

muyuu 14y ago

That's the Perl school of thought that basically finished Perl as a language for big projects. Personally, I have 20 years of C programming experience and I prefer to avoid clever tricks when they add no effective advantage. Making code shorter is not the end-all of programming. Code is written for people to understand rather than for computers to execute (quoting Sussman). It's fine to strive for efficiency since we're talking about OS development here, but it's not the case in this bit of code really, is it? What is more likely to confuse a maintainer, an extra level of indirection or an extra trivial "if"? However if you are committed to do all the maintenance yourself, then you can pick as you wish.

mtoddh 14y ago
That's the Perl school of thought that basically finished Perl as a language for big projects. It's a great point, and I hated Perl for this very reason. And I'm sure some of it is my defensiveness since this is how I program. But some of it is also my concern that it might signal, during an interview say, that the candidate might not really have a good grasp of pointers. For instance, given the following snippet of code, candidates that didn't really seem to grok pointers wouldn't see that the append() function could not be modifying the list in main(): struct node { int val; struct node *next; }; static void append(struct node *list, int val); int main(int argc, char **argv) { struct node *list = NULL; append(list, 4); ... } And my preference for fixing such an implementation would be to change append to take a pointer-to-a-pointer: static void append(struct node **list, int val); with an implementation like: static void append(struct node **list, int val) { struct node **ppn, *pn; if ( (pn = malloc(sizeof *pn)) == NULL) { perror("malloc"); exit(1); } pn->val = val; pn->next = NULL; for (ppn = list; *ppn; ppn = &(*ppn)->next) /* find tail */; *ppn = pn; } and update the call in main() to append(&list, 4). But as I said, you make a good point, and I agree that your method is the safer of the two options from a maintainability point of view.