91–100 of 105 posts
I hate to say that, but I just seem to have broken it. Here's how: I put 0.1 in A1, 0.2 in A2 and =A1+A2 in B1. Now B1 displays "=A1+A2" instead of the result.
Looks like any decimal place breaks it. Whole numbers only. But hey, whaddaya want for 220 bytes?!?
Earlier quoted context omitted.
yes hack yourself. bravo :) I guess you would have to sanitize when you save and/or load the spreadsheet
> I guess you would have to sanitize when you save and/or load the spreadsheet Sanitizing? No chance. Either you have a dedicated expression parser, or you run it directly throgh eval. There is no reliable middle ground. Decades of security failures of so-called "sanitizers" show this pretty clearly. (Even if you manage to create a perfect sanitizer today, wait a few months, new features are added to the browser, and…
If your whitelist allows a wide range of constructs, it isn’t much easier to check that an input is in the allowed set than to write an evaluator that is limited to that set, so it may not be much of an advantage to have a more powerful ”eval” lying around.
Earlier quoted context omitted.
Well, this spreadsheet as it is now isn't very much useful. In fact it is annoying at best. Only programmers will find it amusing and precisely because of how small the code is. No one is actually going to use it ever.
good thing we made it just for fun, then
If we're using ES2015, why not save a byte? (o=b=>{for(j in a)for(i in a)y=a[i]+-~j,b?document.write([[" "][i]]+` `):eval(y+(".value"+o[y]).replace(/[A-Z]\d/g," +$&.value"))})(a="ABCD")
of course! Thanks, I'm adding this enhancement on github!
(o=b=>{for(j in a)for(i in a)y=a[i]+j,b?document.write(``):eval(y+(".value"+o[y]).replace(/[A-Z]\d/g," +$&.value"))})(a="_ABCD")I'm concerned about the lack of type annotations. What about XSS prevention? Maintainability? An API? How are people supposed to use this code in future projects? Your variable names don't conform to Code Complete. This code smells funny. Haven't you read clean code? And I don't think it's general enough. What if people want to add columns, but preserve formulas? What made you think you shouldn't use React for this?…
Earlier quoted context omitted.
XSS prevention, maintainability, code reuse, good variable names, good-smelling code, readability, and using popular libraries are not "over-engineering". They are 95% of what makes someone a good employee instead of a shitty one. With modern languages and tooling, you can have the benefits of most of these things at little-to-no additional cost. If any of these require something complicated and "over-engineered", I'…
No. Rule one is making code that works correctly and quickly, in a short about of time. This is 100% of the job. If you think that "maintainability" and "readability" and "popular" libraries, and "code reuse" and "good variable names" and code that "smells good" to you, help someone do that, then great: That's an argument we can have just by pointing to anyone who gets rule one without those things. However. There's…
I think you totally understood my humor. Thanks!
I saw a good blog in 2011 about how it is a waste of time to overbuild things since mostly you are only ever going to use that code for the specific purpose you are writing it, and you'll likely never need to generalize and you'll probably chuck it out anyway and start from scratch.
Obviously there are a bunch of caveats to that and it's not always true that's the case but I think it's a very useful counterpoint to the profession's current best-practice obsession. If you keep it in mind, alongside all the best practices, and you make a choice about approach in any given situation based on appropriateness, rather than just robotically applying best practices or giving into that common Engineer's temptation to overbuild, this counterpoint can help you build quickly just what's needed, which is effective, exactly like you said.
Earlier quoted context omitted.
of course! Thanks, I'm adding this enhancement on github!
Here's another char off: (o=b=>{for(j in a)for(i in a)y=a[i]+j,b?document.write(` `):eval(y+(".value"+o[y]).replace(/[A-Z]\d/g," +$&.value"))})(a="_ABCD")
Earlier quoted context omitted.
Here's another char off: (o=b=>{for(j in a)for(i in a)y=a[i]+j,b?document.write(` `):eval(y+(".value"+o[y]).replace(/[A-Z]\d/g," +$&.value"))})(a="_ABCD")
awesome! (oh noes, it gets rid of the +-~j trick! :D)