4 ms·

i had to write very similar code (deleting from a linked list) a couple of days ago. i wasn't the easiest code to write, and i needed several iterations before

i had to write very similar code (deleting from a linked list) a couple of days ago. i wasn't the easiest code to write, and i needed several iterations before my tests were ok, but i remember feeling happy that the final result was clear and correct. i just checked it and, yes, i used "two stars". now i'm reading all the comments here, which are predominantly critical, calling this "clever" code. and it struck me just how lucky i am to work with decent programmers. where this kind of thing is considered quality work, not "showing off". what i don't understand is why the other commenters here use pointers at all. couldn't you rewrite this to use arrays with integer indices? then you wouldn't need any stars (or very few), and it would be even "easier". well, that's not true. i do understand. everyone thinks their own level is the correct one. but still, i have sometimes been lucky enough to work with people who knew a lot more than i did. when i was in that position i didn't think they were "showing off". i thought they were awesome and tried to learn from them.

danabramov 14y ago
>it struck me just how lucky i am to work with decent programmers. where this kind of thing is considered quality work, not "showing off". My rule of thumb is I can write “clever” code if I make sure it would be easy to debug for me or anyone else. This usually includes indented logging for anything complicated, good choice of variable names and plenty of debug assertions that would fail with a meaningful message if something went wrong. When the deadline comes and you're dealing with an obscure bug in a clever code that looks right but is difficult to reason about, you'll be damning it.
- deleted 14y ago
  [deleted]
betterunix 14y ago
"i had to write very similar code (deleting from a linked list) a couple of days ago. i wasn't the easiest code to write, and i needed several iterations before my tests were ok, but i remember feeling happy that the final result was clear and correct." How was this not easy code to write? I imagine it would have looked like this, but in your language of choice: (defun remove-if (lst pred) (if (null lst) nil (if (funcall pred (first lst)) (remove-if (rest lst) pred) (cons (first lst) (remove-if (rest lst) pred)) ) ) ) This is straightforward and basically follows from the definition of a list: either null (empty) or a pair whose second element is a list. The C version is uglier because of the need to deallocate removed nodes, track pointers, etc., but it still follows from the definition of a list.
- deleted 14y ago
  [deleted]
- andrewcooke 14y ago
  eh, what do you want me to say? everyone else here is calling me a smartass and you're telling me i'm an idiot. it was c. i made some mistakes. i fixed them.
  - betterunix 14y ago
    Well I don't mean to say that you are an idiot; I really am curious about what made removing nodes from a list difficult. One of the things that makes linked lists great to work with is how easily nodes can be removed or inserted. Personally, I would be inclined to blame C as a language, rather than you as a programmer. You basically did that anyway: "it was c. i made some mistakes. i fixed them."
  - eps 14y ago
    > everyone else here is calling me a smartass and you're telling me i'm an idiot. This is pure gold :D

danabramov 14y ago

>it struck me just how lucky i am to work with decent programmers. where this kind of thing is considered quality work, not "showing off". My rule of thumb is I can write “clever” code if I make sure it would be easy to debug for me or anyone else. This usually includes indented logging for anything complicated, good choice of variable names and plenty of debug assertions that would fail with a meaningful message if something went wrong. When the deadline comes and you're dealing with an obscure bug in a clever code that looks right but is difficult to reason about, you'll be damning it.

deleted 14y ago
[deleted]

betterunix 14y ago

"i had to write very similar code (deleting from a linked list) a couple of days ago. i wasn't the easiest code to write, and i needed several iterations before my tests were ok, but i remember feeling happy that the final result was clear and correct." How was this not easy code to write? I imagine it would have looked like this, but in your language of choice: (defun remove-if (lst pred) (if (null lst) nil (if (funcall pred (first lst)) (remove-if (rest lst) pred) (cons (first lst) (remove-if (rest lst) pred)) ) ) ) This is straightforward and basically follows from the definition of a list: either null (empty) or a pair whose second element is a list. The C version is uglier because of the need to deallocate removed nodes, track pointers, etc., but it still follows from the definition of a list.

deleted 14y ago
[deleted]
andrewcooke 14y ago
eh, what do you want me to say? everyone else here is calling me a smartass and you're telling me i'm an idiot. it was c. i made some mistakes. i fixed them.
- betterunix 14y ago
  Well I don't mean to say that you are an idiot; I really am curious about what made removing nodes from a list difficult. One of the things that makes linked lists great to work with is how easily nodes can be removed or inserted. Personally, I would be inclined to blame C as a language, rather than you as a programmer. You basically did that anyway: "it was c. i made some mistakes. i fixed them."
- eps 14y ago
  > everyone else here is calling me a smartass and you're telling me i'm an idiot. This is pure gold :D