Hacker News Reader

Comment by alfonsodev | Hacker News Reader

The ninja code section is pure sarcasm, right?

I'm not sure now which sections are and aren't.

That page has an 'irony warning' so just watch out for those on other pages!

It might just be my sense of humour (I'm the sort of person that doesn't need an '/s' tag and feels that it shouldn't be necessary if you told the joke properly), but it was pretty obvious to me even without the irony warning that the page was intended as a joke.

It looks like it was heavily inspired by the classic 'Tao of Programming' [0]. It uses a very similar style and even quotes the actual Tao Te Ching.

[0] http://www.mit.edu/~xela/tao.html

I am with you on not wanting or needing to see /s ... but on a tutorial, where people actually struggle to understand anything at first read, using unmarked irony is maybe not the most helpful for them.

Oh and a second thought on /s. For some time I only got my news through satire sites like the onion. And after I switched back to "real news" sites, I could not believe it was not satire. I mean come on, the world and the internet was always full of dumb people, but when even very high ranking people and institution say really out of the world things in all seriousness - I came to the conclusion, marking irony as irony is sadly sometimes important, in those interesting times we live ...

Yeah, when we live in a world where people legitimately believe that Bill Gates is trying to use COVID vaccines to install microchips into people, you can't always be sure that someone giving an insane opinion isn being ironic or sarcastic.

I mean, we allways had flat earthers (even though I couldn't believe they were serious either, when I first stumbled upon them).

But this new level is a bit unsettling.

The Ninja code section seem to have been largely based on this classic article, which I personally found more humorous to read: https://github.com/Droogans/unmaintainable-code?fbclid=IwAR1...

Interestingly Golang encourages one letter variable names and it's not sarcasm this time : https://github.com/golang/go/wiki/CodeReviewComments#variabl...

Golang's landscape is full of one letter variables and abbreviations and it's not great.

It's only encouraged within certain contexts. Like it says, short lived stuff can be named "x" or "i". We already do this in almost every language. "c" for "count" or "i" for "index" isn't specific to Go, I've seen and done that in every language I've used.

Stuff that isn't easily understood should be named appropriately but shortness is encouraged.

If you're storing an index in a global variable or a struct field then it should be called "index" not "i".

Method receivers are usually always kept short because they're pretty self explanatory and the first thing you look at in a function.

i and j are very understandle.

I did browse the go code randomly and for example t, s, and b are terrible variable names in my opinion in this example : https://github.com/golang/go/blob/3ce865d7a0b88714cc433454ae...

You can find a lot of code like this.

That's easy. `b` stands for file

That strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?

template, bytes, string.

`bytes` is the name of a stdlib package. `string` is the name of a built in type. `template` is technically available, but only because it’s the name of this package, so it can’t refer to itself.

True, but they are all available. The stdlib bytes packages is not loaded, and it's valid to use `string` as a variable name, I just tried.

But even if these names were not available, I don't think using `tpl` or `t` or `b` is what should be preferred.

template, file, text

Is file a file object? A file path?

All three are “the template”. So, they use polish-ish notation: the template as []byte, template as string, and template as *template.Template.

In just two hours we discovered so much! Let's keep digging.

I’m not sure I follow. Is two hours a long time or a short time?

I use Go a lot, so I’m used to it’s conventions. b for bytes is obvious to me because I know ReadFile returns bytes (not a file handle or a buffer), but I can see why if you lack context, it can look odd. OTOH, I don’t use Rust, so when I read snippets with 'a lifetimes, they always look “wrong” to me.

Sure, what bothers me is how inconsistent it is. Function parameter of type Template is `t` but local variable of type Template is `tmpl`.

Yes, I would have named the other one returnTmpl or something.

I never understood that. Is it really that hard to spell out full variable names? It’s so much more legible, there is autocomplete on virtually any editor (even the ones that aren’t IDEs), and you write code once but read it hundreds of times. Why even try to save 8 bytes at the expense of readability?

Short variable names make code more readable in some scenarios, not less.

  fooBarBazThings.each(t => t.DoThing())
  for (int i = 0; i < len(things); i++) { // i used here }

Some local code patterns are seen so often you understand it in one go. Something like

  fooBarBazThings.each(fooBarBazThing => fooBarBazThing.DoThing())
  for (int thingIndex = 0; thingIndex < lengthOfThings; thingIndex += 1) { // thingIndex used here }

Just clutters things up.

I disagree. I always use descriptive variable names. I have no idea what ‘t’ is. ‘thing’ is 4 bytes more. Not the end of the world, but much more readable. Same for ‘i’ vs ‘index’.

Modified obfuscator can make your code even more readable. It can simplify functions in addition to variables. Also, it improves job security, which is important in times of covid.

This is a bit of a false dichotomy, because the names don't have to be that long.

  fooBarBazThings.each(thing => thing.DoThing())

It's more useful when the receiver of the method doesn't tell you as much, eg:

  getRecentPurchases().values().forEach(price -> priceStats.accept(price));

I kind of agree with their reasoning, the exception being when you can have a lot of complicated looping/control flow breaks or transient variables close to their usage. Seeing 'array[i][j][k]' is never fun.

The section is clearly dripping with irony. They even have an "Irony detected" box at the very top which acts as the sarcasm/satire tag so many people seem to use to bang over our heads that it's not serious.

It has an alert at the top that says, "Irony Detected".

It is hilarious. Lao Tzu quotes make it simply perfect.

It is funnier to me because the quotes are actual historical quotes (to be fair, there probably was no "Laozi" historically), whereas you see fake quotes for Laozi/Confucius/Buddha all over the internet.

Reply on news.ycombinator.com