Hacker News Reader

Comment by Jaruzel | Hacker News Reader

I don't understand why people are dissing this.

It does what it's designed to do, and fills a specific need for one website. It's not there as a teaching aid, nor is it meant to be shared for other people to use elsewhere.

Not everything has to be gold-standard code full of perfect variable names, extensive comments and good whitespacing. If you have a day job that isn't primarily writing code, and/or you are likely to be the only person ever working on that code, who cares if it's not up to the standard that people around here seem to expect of every project?

As long as the code works, anything else is just gravy. If you were to peel back the layers on all the major websites out there, I'm sure you'd find less than stellar code everywhere.

View on HN

I believe there is a difference between gold-standard perfect code and just making "beginners mistakes".

It costs almost nothing more to write "event" instead of "ev" or "removeElement" instead of "remEl", but it makes the code much more readable. You might gain 1s for writting remEl instead of removeElement but you will loose more seconds in the future trying to remember what remEl stands for, or having to check what abbreviation you chose for that function.

It's just something programmers learn with experience (even when working alone) : abbreviations are a false good idea, and people are just pointing that out.

> It costs almost nothing more to write "event" instead of "ev" or "removeElement" instead of "remEl", but it makes the code much more readable.

No, it doesn't. Unless you're an absolute beginner, it takes you a couple of seconds to realize that in this codebase, "ev" (or "evt" or even "e") means "event". The same goes for "remEl". If that's consistent, then it's not a big deal at all.

Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff.

>Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff.

Only to a point, otherwise minified js would be more legible than plain source. It takes "a couple of seconds" to scan the codebase and find out what el or ev refer to, but it would take zero seconds if they were just called "event" or "element."[0] There's no gain in readability from shaving off one or two characters in that case. It just "feels" more efficient because it resembles the common style of lower level code.

[0]Assuming those aren't reserved words in javascript, I don't know.

Of course, up to a point. The same goes for very long but extremely descriptive variable names. Hence, it is a tradeoff.

You are allowed to use both event and element, as they aren't strictly reserved keywords.

I think it's generally frowned upon, though. For example, I believe "event" is defined as a global in browsers (on window, perhaps?), so you run the risk of shadowed variables and accidentally referring to the wrong thing.

Having anything take a couple of seconds more to read something is by definition making something less readable.

Okay so perhaps a couple of seconds doesn't matter. How many seconds does?

There's an objective definition for readable?

426.

Less characters really only makes sense in some scenarios, e.g. "unimportant" variables (for loops, temporary storage inside a procedure). Verbose 'variablesToKeepTrackOfPositionInThisLoop' is obviously pointless when 'i' will do.

However renaming "important" things to make it quicker to read or type is, in my experience, a mistake if your code base is more than just a handful of files. Descriptive names make it much easier to understand the code which is more important in my experience. As the number of code files gets beyond a few files any benefits you get are rapidly lost because now you need to keep all that knowledge in your head and start having to jump around between 5, 10, 20 or more files to work out what everything is let alone what it is doing. This is why naming stuff in code is so important (and sometimes so hard).

Golang has a good philosophy on this front: https://github.com/golang/go/wiki/CodeReviewComments#variabl... tl-dr: the further from its declaration that a name is used, the more descriptive it should be.

This sort of attitude about brevity & speed appears to be a common problem with some developers I come across - they are absolutely obsessed with "productivity" when it comes to writing code. They've just got to have their 97 plugins/extensions to their editor and they simply must have their finely-honed emacs keybindings. If you are focusing on just churning out code as fast as humanly possible (i.e. "productivity"), then your job as a programmer can probably be safely replaced with a couple of shell-scripts.

I've never been in a situation where the limiting factor in programming has been how fast I can read it or write it - the limiting factor has always been understanding the problem at hand, and designing a solution that solves the problem and is maintainable.

> Verbose 'variablesToKeepTrackOfPositionInThisLoop' is obviously pointless when 'i' will do

Based on a Fortran convention, IIRC. Within a web setting, "el" and "ev" are extremely conventional.

> tl-dr: the further from its declaration that a name is used, the more descriptive it should be.

Interestingly, this results in more or less the opposite of entropy coding

The point I'm making is not "use short variables everywhere", it's that in this case, the verbose alternative is not "much more readable".

Abbreviating "element" to "el" or using "attr" instead of "attribute" (etc.) can significantly reduce noise in web client code. Everybody either knows what it means, or they shouldn't be editing the code in the first place.

I prefer "elem" as then it's easier to distinguish from "event" than it is for "el" and "ev".

> Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff.

It might, in a specific circumstance, while in another circumstance it might make the code significantly less readable. That is an indication that number of characters is probably not a good metric for adjusting readability.

Couldn't agree more, sometimes too long makes things so much worse. I don't know why this is more common in Java code bases, but I've definitely seen function calls that take 6+ lines (have to maintain that 80 column limit) due to horrible naming. By the time I finish reading that, I've already forgotten what the base class is even called.

However, I've also seen large classes with members like "stN" for "set N". WTF is N, and why can't we just type set, that one char doesn't save anybody any time at all. Or nested loops with i & j reversed, just to make it especially painful.

Unless you're a machine, don't know what to tell you.

>If you have a day job that isn't primarily writing code, and/or you are likely to be the only person ever working on that code, who cares if it's not up to the standard that people around here seem to expect of every project?

Future you that has to decipher the code. Why make it hard on yourself? Software is a living thing eventually a decision will need to be made about it and without understanding what it does it's easier to make suboptimal assumptions.

> Future you that has to decipher the code. Why make it hard on yourself? Software is a living thing eventually a decision will need to be made about it and without understanding what it does it's easier to make suboptimal assumptions.

To the defense of the title, in my experience, whenever label "hacker" was used on programmer or code, it meant "difficult to read, full of hard to maintain shortcuts and tricks" kind of code. Really always, I don't ever remember it to be used in any other sense.

True this

Eh, it's only 150 lines of simple functions without external dependencies. It's simple enough to understand and modify on the spot. As long as these are not expected to grow significantly in the future, I don't see why it'd be making it hard on yourself (and if it does grow, then it can always be refactored).

This 100x times. There is very little code there. Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly, and that's not even counting the complexity of the deployment pipeline. This here, it's just 150 lines of plain code. It's not hard to work with something like this.

I'm not saying a rewrite is necessary at all, but refactoring this code to use more modern standards would NOT increase the line count at all, my guess it it might cut it by 15%+ in total size if you leveraged the beautiful builtin functions. Compare these:

    function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} }

Could turn into something like this:

  const addClass = (el, cl) => el.classList.add(cl)

Not only is is shorter, but it's more readable too!

el.classList isn't supported by IE < 10

And is it accurate to describe IE < 10 as "more modern"?

It isn't, and I don't think I have.

My point was that using a "more modern standard" would break hn for people using legacy browsers.

> Not only is is shorter, but it's more readable too!

And won't work on IE. Not just because of el.classList, but also because of the arrow notation. So by doing this change, you either have to ditch one of still used browsers, or introduce a stupidly complex transpilation chain into the mix.

I'm aware, but I'm responding to the myth of:

> Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly

That's just not true, and nowhere did that person say: "Because of legacy IE support requirements", they only mentioned "modern webdev standards".

Are you suggesting arrow functions, and classList aren't modern standards then?

I was that person, and what I meant was that "modern webdev standards" would include modules and features requiring transpilation, which would introduce many dependencies, all of which count into code size (you have to keep track of them mentally).

Why/where would modules be necessary here? Just because there's a feature now that didn't exist years ago doesn't mean it's the right time & place to use it. The code works as-is, a small refactor to leverage built-in functions to do some of the trickier logic parts would make this code a breeze. There's no need for something like Babel to help out with a small refactor.

The code is entirely self-contained. That's what makes it easier for future-you to understand and decipher. Dependencies won't have gone out of date, library versions won't have moved on, APIs won't have disappeared, etc.

> As long as the code works, anything else is just gravy

I'll try to incorporate this in my next job interview :)

The code is readable. There is no problem.

> As long as the code works, anything else is just gravy.

How did you end up with this opinion? That's an unpopular opinion even when considering the qualifiers you've listed in the paragraph above.

I think there are two ways of looking at this.

From the top down (strategic), and from the bottom up (tactical).

Depending on your perspective, you will likely fixate on different things.

If you're starting from the bottom, you'll probably be more interested in the coding choices made by the developer.

If you're coming from the top, you'll probably look at the goals of the site and whether the code met them, and then consider other details like optimization and cleanliness to be secondary ('gravy').

When I was in biz-school in the 90s, we used to spend a lot of time talking about effectiveness (the end result does what it needs to do) and efficiency (the end result does what it needs to do and is optimized for -insert criteria here-).

Ideally, you get to be both effective and efficient. If, however, you can only be one, it's better to be effective.

> As long as the code works, anything else is just gravy.

“It works” is one of the lowest imaginable quality bars for software to meet, one notch up from “It compiles.” Through my career I’ve worked with way, way too much code where the developer stopped at step one (it works).

Yes exactly. KISS people!

> As long as the code works, anything else is just gravy.

Nonsense. Maintainability almost always matters.

As the adage goes: code shouldn't merely work, it should clearly work.

> If you were to peel back the layers on all the major websites out there, I'm sure you'd find less than stellar code everywhere.

Indeed, but Sturgeon's Law shouldn't make us feel better.

In this particular case, the fact that the code is so terse makes it immensely more maintainable than a whole architecture + framework.

The HN code is meant to be understood as a self-contained piece, and that's contextually very different from most code out there.

> Nonsense. Maintainability almost always matters.

The last three large corporations I worked for never cared about maintainability because the application or portal would only be in use for maybe a year or 18 months before a complete rewrite or total redesign.

All of the recent projects I've been on take the same approach. Get it stood up, make it look pretty and release it. Because agile development makes business owners believe it only takes a few days to build Rome now, maintainability is never a consideration on any of the projects I've been on. Even senior devs are saying, "It's pretty hacky to get this to work, but it works" is a common troupe on our teams. I agree maintainability should be important, but on the agile projects I've been on, nobody cares about it.

To some degree I think executives do it on purpose so they can create more work for themselves in the future. They can pick it apart, ask for a bigger budget, hire more devs and use some shiny new technology to build it over again. Rinse, repeat.

> The last three large corporations I worked for never cared about maintainability because the application or portal would only be in use for maybe a year or 18 months before a complete rewrite or total redesign.

The first significant web app that I wrote had a similar approach. I was a new developer, but I had a good idea and they hired a manager and a couple of other developers to flesh it out. No need to hire a senior dev, because it was just a POC. We weren't even part of IT, so anything we built would of course only be in use for a few months before IT would allocated "real" developers to rewrite it.

Four years after I left that job, I got a call one day that the site was down and they couldn't fix it. After ten minutes on the phone with a former colleague reading me the logs out loud while I read through an old copy of the code that I (thankfully) still had on an archived drive, it turns out that the LDAP server's address had changed. We updated that and it came back.

Out of curiosity, I had them run `uptime` on that box. It had been up for six years - the two years I was there, and the four since I'd left. Not only had the application continued to function and be used... the box it was running on hadn't been updated restarted since it was built. It hadn't gotten updates since I'd left either.

The point of this story is simple: there is no such thing as code where maintainability doesn't matter, because there is no such thing as "temporary" code. Code can get retired or refactored away, sure, but there is absolutely no way to tell ahead of time if any given code snippet falls into that category.

the application or portal would only be in use for maybe a year or 18 months before a complete rewrite or total redesign

Why on earth is this such a popular idea? Do customers somehow prefer to see all the buttons in new places and old urls broken every other year?

I'm honestly not sure. When I first started out, all the applications I used had been built five years prior. We made small tweaks and continued to use them because they just worked

Now? I think newer technologies come out faster and capture people's attention. They want to use the new shiny thing. I think the "business people" want to have a big budget project to get recognition within large orgs. I think developers want to use the latest and coolest stuff. I think people feel like we already live in a disposable culture, why would our sites and apps be any different? You combine all of these and suddenly the pressure and inertia not to move or rebuild or redesign regularly is too much to overcome.

I still remember going to a ReactJS class and the guy running it kept saying, "Don't get me wrong, BackboneJS is still a hell of a library and is still relevant and awesome to build stuff with BUT React does a few things better."

This is where we are. Huge financial investments, time and energy to get a 3-5% bump in efficiency? Doesn't make sense to me.

Reply on news.ycombinator.com