8 ms·

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,

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.

pacifika 8y ago
>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.
- watwut 8y ago
  > 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.
  - yani 8y ago
    True this
- kruczek 8y ago
  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).
  - TeMPOraL 8y ago
    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.
    - err4nt 8y ago
      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!
      - ht85 8y ago
        el.classList isn't supported by IE < 10
        err4nt 8y ago
        And is it accurate to describe IE < 10 as "more modern"?
        ht85 8y ago
        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.
- barrkel 8y ago
  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.
paulintrognon 8y ago
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.
- xigma 8y ago
  > 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.
  - krapp 8y ago
    >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.
    - xigma 8y ago
      Of course, up to a point. The same goes for very long but extremely descriptive variable names. Hence, it is a tradeoff.
kowdermeister 8y ago
> As long as the code works, anything else is just gravy I'll try to incorporate this in my next job interview :)
lolc 8y ago
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.
MaxBarraclough 8y ago
> 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.
- norswap 8y ago
  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.
- at-fates-hands 8y ago
  > 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.
  - LyndsySimon 8y ago
    > 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.
slantyyz 8y ago
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.
darepublic 8y ago
Yes exactly. KISS people!
h1d 8y ago
> who cares You will. > As long as the code works, anything else is just gravy. These attitudes are really making some projects collapse like hell. If you agree to it, you need to stop writing code unless it's just for you. > I'm sure you'd find less than stellar code everywhere If this makes you feel proud of writing shit code, you need to stop as well.
- dang 8y ago
  Please don't cross into personal swipes like that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
ryandrake 8y ago
> 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).

pacifika 8y ago

>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.

watwut 8y ago
> 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.
- yani 8y ago
  True this
kruczek 8y ago
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).
- TeMPOraL 8y ago
  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.
  - err4nt 8y ago
    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!
    - ht85 8y ago
      el.classList isn't supported by IE < 10
      - err4nt 8y ago
        And is it accurate to describe IE < 10 as "more modern"?
        ht85 8y ago
        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.
barrkel 8y ago
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.

paulintrognon 8y ago

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.

xigma 8y ago
> 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.
- krapp 8y ago
  >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.
  - xigma 8y ago
    Of course, up to a point. The same goes for very long but extremely descriptive variable names. Hence, it is a tradeoff.

kowdermeister 8y ago

> As long as the code works, anything else is just gravy I'll try to incorporate this in my next job interview :)

lolc 8y ago

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.

MaxBarraclough 8y ago

> 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.

norswap 8y ago
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.
at-fates-hands 8y ago
> 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.
- LyndsySimon 8y ago
  > 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.

slantyyz 8y ago

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.

darepublic 8y ago

Yes exactly. KISS people!

h1d 8y ago

> who cares You will. > As long as the code works, anything else is just gravy. These attitudes are really making some projects collapse like hell. If you agree to it, you need to stop writing code unless it's just for you. > I'm sure you'd find less than stellar code everywhere If this makes you feel proud of writing shit code, you need to stop as well.

dang 8y ago
Please don't cross into personal swipes like that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

ryandrake 8y ago

> 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).