251–260 of 302 posts
Sandi Metz has a talk where she speaks about her dislike for if https://www.youtube.com/watch?v=OMPfEXIlTVE
I would imagine Linus to disagree with Sandi's approach, though. She is never eliminating the if (as in: the conditional jump), just moving it from plain sight into the magic of dynamic method dispatch.
I think "competitive" (i.e. solving algorithmic challenges for fun) coding really gives you some insight into how to write code that's short and to the point. The user with the most reputation on LeetCode, for example, consistently posts solutions that are surprisingly short, efficient, and readable. https://discuss.leetcode.com/user/stefanpochmann (some random examples) https://discuss.leetcode.com/topic/18731/7-lin…
Side note - blindfold Rubik's Cube is way easier than you think. If you're a programmer and can already solve one sighted, I'd imagine you could learn Classic Pochmann in a week.
I dunno, the first example seems unsatisfying. The original has that ugly condition, the "good" version seems overly clever. And for all the talk of taste and aesthetics, both versions ignore an elephant in the room: defensively dealing with `entry` being absent from the list. Not that I've never abused addresses like this. But having written this multiple times, I currently prefer something like this: remove_list_en…
There's a compromise enterprise developers should recognize from CS classes that's almost elegant enough for the kernel crowd: use a sentinel node for the element before the head. The edge case is eliminated, and no more &(*)->; ASCII Cthulhu.
Linus basic point stands although his example isn't very good.
I don't know how to reconcile Linus's track record is of indisputable brilliance and success (I use Linux and Git on a daily basis and am eternally grateful for both), with the fact that I would absolutely DESPISE working with a peer with the kinds of attitudes and opinions on coding that Linus has. I think the problem I have is that a lot of people use Linus's examples and stories as justification for their own subo…
I get what you are saying and I agree somewhat, but there are also some lessons to be learned from Linus and things to consider. I especially agree that many lesser talented people use his behavior as a justification for their own. I disagree that at least some of his lessons or behavior is detrimental. A good realization in life that many of us have is, "Most people are wrong about most things most of the time." Thi…
The way this seems to work around here (I'm a Canadian, and I've worked in the US, too) is that it is just fine to be directly critical of others if you are talking downward socially. Boss to subordinate, parent to child, teacher to student, it's just fine. But it's not really OK peer-to-peer or upward. And if you insist on being bluntly critical peer-to-peer or upward, what you are saying carries the additional meaning that the person is a real bozo or messed up really badly, so you are justified in talking down to them, as a sensible knowledgeable person dealing with a fuck-up.
That said, it is possible to convey criticism sideways or up, but it requires some social tap-dancing to emphasize that you are only telling the person they are mistaken, not that they are laughably hilariously wrong. The simplest of them is understatement. Compare "That doesn't look right to me. Could you check that it's doing what you expect?" to "No. That's wrong."
Next time you are tempted to be bluntly critical, keep this in mind. Your message may be taken as much more severe criticism than you intend.
Finally, let me add that this rule is not universal. In some cultures and subcultures, it's much more OK to be directly critical. In others, presumably, it's even less tolerable.
Earlier quoted context omitted.
Really, if you think the good version is overly clever, you probably have a very fundamental problem with your abstract reasoning. A very human one, as history is full of people having that problem--and ultimately, the good version taking over anyway. How about this: subtract(n){ if(n==0){ return m; } r=m; for(x=0;x People for a long time had strong objections to a number "0", because it doesn't make sense to have a…
".. if you think the good version is overly clever, you probably have a very fundamental problem with your abstract reasoning.." Just to show that you're talking out your ass, here's a code snippet where I did the address of address thing in precisely the same "remove from linked list" situation. In a VM and programming language and operating system that I wrote from scratch[1]. https://github.com/akkartik/mu/blob/a9…
I'm no sure what exactly that code/that change is supposed to tell me, so I can't tell whether it's a good argument. Mind condensing it down/pointing out what specifically you mean?
> As a general rule I'd recommend not reaching conclusions about people from things they write in a comment on the internet. You're looking at them through a tiny peephole into their belief system. When in doubt, ask questions. "Excuse me sir, do you have much experience with C?", "Are you saying pointers to pointers are always bad?", and so on.
Well, that depends on whether you want to make a point for other people in the discussion or discuss some issue with a specific person. As such, that was not really a judgement of your person, but rather a general statement about a group of people (which obviously might be wrong in some cases).
> (Clever analogy there about 0. Totally agree with it. Utterly non-applicable in this instance.)
You mean not applicable in the case of your code, or in the code in the article, or what else?
(edit: and yeah, I realize how the wording might give the impression that I was talking specifically to/about you, but I really wasn't, I was just using what you wrote as the opportunity, so I ended up addressing you :-)
Earlier quoted context omitted.
I'd add something like assert (head && entry) up there.
A NULL head is not an error (= empty list) and 'assert' would be better as a BUG_ON or panic if it is technically an error.
I wouldn't care, but if you claim to be defensive, go full monty.
Earlier quoted context omitted.
".. if you think the good version is overly clever, you probably have a very fundamental problem with your abstract reasoning.." Just to show that you're talking out your ass, here's a code snippet where I did the address of address thing in precisely the same "remove from linked list" situation. In a VM and programming language and operating system that I wrote from scratch[1]. https://github.com/akkartik/mu/blob/a9…
> Just to show that you're talking out your ass, here's a code snippet where I did the address of address thing in precisely the same "remove from linked list" situation. In a VM and programming language and operating system that I wrote from scratch[1]. I'm no sure what exactly that code/that change is supposed to tell me, so I can't tell whether it's a good argument. Mind condensing it down/pointing out what specif…
Yeah my link is in a strange syntax, but mostly I just wanted to point at the specific line containing address:address, which is the same as a pointer to a pointer. That line is in a function called delete-before-cursor which uses a (doubly) linked list to maintain the state of a text editor.
I came up with this syntax for a teaching environment: http://akkartik.name/post/mu
Earlier quoted context omitted.
A NULL head is not an error (= empty list) and 'assert' would be better as a BUG_ON or panic if it is technically an error.
It is an error though if your code SEGFAULT on NULL head (and this one does). I wouldn't care, but if you claim to be defensive, go full monty.
There is no "SEGFAULT" in kernel code. SIGSEGV is a signal, which is only used at user-level.
NULL dereference in the kernel results in an "oops".
I believe it is also assumed in their code that "entry" is not going to be NULL, meaning "if (head == entry)" will never succeed if head is NULL.
I was given a piece of advice very early on in my career that I've always been grateful for, which is fundamentally the same as this. IF and FOR are both code smells. One case of this is just simplifying loops with some functional goodness var listOfGoodFoos = new List (); for(var i = 0; i VS return listOfAllFoos.Where(x => x.IsGood); But perhaps a more interesting point is it can also be a a sign of DRY gone wrong -…