Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

41–50 of 302 posts

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#41

Earlier quoted context omitted.

Sorry, I should have mentioned that I was not the GP. Even if you use spaces rather than tabs, the idea is the same. Do you mean something like the below? Note: \t represents tabbing (not necessarily the number of tabs, just spacing using tabs), and _ represents spaces. int f(int x, \t\t__int y) // one 4-width tab, pad with spaces { \t\t// do stuff; } int f(int x, \t\t\t\tint y) // one 8-width tab, whoops { \t\t\t\t/…

Even if you use spaces rather than tabs, the idea is the same It's not, because there does not exist an editor that is smart enough to recognize that these 4 spaces are indentation tabs while these 4 spaces are spacing spaces. It's not impossible, but show me an editor that does it today (especially with C++) and I'll eat my hat :D I agree with you that if you're using actual tabs for indentation it works fine.

>It's not, because there does not exist an editor that is smart enough to recognize that these 4 spaces are indentation tabs while these 4 spaces are spacing spaces.

Oh yes I see your point. All the more reason to use tabs for indentation and spaces for alignment. :)

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#42
I've been told many times that it's better to eliminate edge cases. I still don't really believe it as a universal law.

When explaining the algorithm "remove an element from a linked list" to someone else, I would say "starting at the head, go along the list until you find the element; then delete the element". When explaining the algorithm "delete an element from a linked list", I would say "if you're at the head, update the head to be the next element; otherwise update the `next` property of the previous element to be the `next` property of the current element". It's so naturally a two-case problem that I'd be really surprised if anyone came up with the one-case answer first. Therefore, the two-case answer is the more readable to someone who has not seen the code before, because it corresponds to their intuition about how the algorithm should work.

As a bonus, it's clear to me that the naive algorithm is correct, but I have to do mental work to convince myself that the one-liner algorithm is correct. (I'm saying nothing about the code; only the algorithms.)

I agree much more with the reduced complexity of the later example (initialising the edges of a square), and I actually think it's worth double-counting the corners in this instance because the code is so much cleaner. (EDIT: Although I suppose the easy fix doesn't detract from the ease-of-reading, so actually it's avoidable.) In that instance, there's doubt about which is the natural algorithm to pick: one could conceivably come up with "initialise the top and bottom, then initialise the left and right", or "initialise the zeroth element of each side, then the first of each side, then…" as one's first attempt at solving the problem. Therefore I like this particular simplification.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#44

Not being used to C syntax, I took this as a typo at first: indirect = &(*indirect)->next; The position of the parentheses make it look like you're dereferencing only (* indirect). But on second look, you need the parens there so that it's (* indirect)->next as opposed to indirect->next. Then the & operates on the whole thing. I'd be tempted to wrap it in a second set of parens for clarity, but perhaps it's entirely…

To me, its 'clever' code.... i.e. it should be simplified. This is not good code, it requires too much thought to realise what its doing.

It's busier to look at due to the syntax of the language, but if you're comfortable with pointers one could argue that it's conceptually simpler than the first example. And since linked lists are all about pointers, operating on the pointer directly seems logical.

That said, for someone unused to the syntax (as I am!), I agree that it is definitely harder to mentally parse. So which is objectively better probably depends on your audience.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#45
post #29

Earlier quoted context omitted.

Does it come down to having a deeper understanding of what is available? In your example, I guess a new engineer may not know that Where() is available, but a seasoned engineer should know. I also think that this why the social aspect of code review is so important. It is a knowledge sharing mechanism. edit: grammar

In case any other seasoned C++ engineers are worried that they have missed something big in all the new C++ specs, the above code seems to be C#.

It is, sorry,I should have specified. Also I don't think many people would use a loop like that when foreach is available.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#46

These are great examples, and they hint to, but do not mention, the big counterpoint: development time. In his own examples, the author admitted that though the code was ugly, it worked. He then spent extra time reworking the existing code to make it, well, prettier. "If I had more time, I would have written a shorter letter." -- Voltaire The problem is that, in many (most?) professional settings, the developer is un…

This demonstrates the general move in the marketplace from companies developing software, to instead hacking out quick product for fast money.

The startup mentality has made this worse, and continues to do so.

Good software requires thought and time to get right. Unfortunately, those people buying software are often willing to pay for low-quality hacks these days, in the name of a quick fix.

It's just another commodity now, and as such, like many other products, more about cost than quality.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#47
post #34

Speaking of coding niceties, when I started branching out from bash into a 'real' language, Python, I couldn't find a switch statement. A colleague of mine said that Python didn't have one, and that switch statements were a 'code smell'. I didn't really understand that, and asked about those times that you genuinely could use a switch statement, and the answer was "just use a long if-else function". I can't remember…

If your switch is more than a few lines, the Pythonic way is to use a dictionary, rather than many if-else statements. A dict is roughly as concise as a switch, and it's also much easier to work with and extend.

Following the principle of "There should be one--and preferably only one--obvious way to do it," switches in Python are redundant. If you want branching logic, then use branching statements (if-else). If you want mapping, use a dict. The hiccup is that many programmers new to Python don't actually know what a dictionary is--or at least haven't used one before--so it's far from "obvious" to them to use it.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#49

One anti-pattern I've seen a few times, across multiple codebase and companies, is the for i in 1...cases: switch(i) To me, his first example fits this perfectly, except he is using ifs instead of a switch. Basically, if you are generating a big, trivial sequence and then filtering it down afterwards, think harder and probably there is a way to generate the sequence you are actually after directly.

> One anti-pattern I've seen a few times, across multiple codebase and companies, is the for i in 1...cases: switch(i)

Also known as the "for-case" loop. Version 2 is a prime example of this, and what not to do. It processes case 1, then case 2, then case 3, then case 4. The author rewrites it as one loop of 64, but four loops of 64 each would also be acceptable.

> To me, his first example fits this perfectly, except he is using ifs instead of a switch. Basically, if you are generating a big, trivial sequence and then filtering it down afterwards, think harder and probably there is a way to generate the sequence you are actually after directly.

Now you're talking about a different problem. The conditionals in the first version do not iterate through like code doing "switch(i)". I agree that it's better to directly generate than to filter, but that's a totally separate anti-pattern.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#50

Not being used to C syntax, I took this as a typo at first: indirect = &(*indirect)->next; The position of the parentheses make it look like you're dereferencing only (* indirect). But on second look, you need the parens there so that it's (* indirect)->next as opposed to indirect->next. Then the & operates on the whole thing. I'd be tempted to wrap it in a second set of parens for clarity, but perhaps it's entirely…

To me, its 'clever' code.... i.e. it should be simplified. This is not good code, it requires too much thought to realise what its doing.

Worse is better
Post reply on HN