|
Chin Strap posted:Has anyone posted JSFuck yet? http://thedailywtf.com/articles/bidding-on-security And let's not forget about this: http://utf-8.jp/public/aaencode.html HardDisk posted:This is actually really clever, but I've found that clever code is usually harder to debug for not that much gain. I also find that ternary operators are a kind of gateway drug for clever code. Cheers - I've got the same objections about ternaries and that's why I try not to use them in production code Still, it's easier for me to follow, even if there's an if inside an if
|
# ? Mar 1, 2016 15:22 |
|
|
# ? Jun 8, 2024 05:41 |
|
One problem I have with the triple ternary cuteness is that it's a very different syntax for the three-condition case, versus four or two or seven. Precedence is sure nicer, though.
|
# ? Mar 1, 2016 15:24 |
|
PHP has a bug (since 2012!) that gives you the incorrect date when it's a leap year depending on the order of the format string.PHP code:
|
# ? Mar 1, 2016 15:57 |
|
Chin Strap posted:Has anyone posted JSFuck yet? http://thedailywtf.com/articles/bidding-on-security Finally, a use for esoteric programming languages!
|
# ? Mar 1, 2016 16:47 |
|
bigmandan posted:PHP has a bug (since 2012!) that gives you the incorrect date when it's a leap year depending on the order of the format string. Since 2012 you say...? How likely is it that this bug was introduced by a "fix" for some other leap year bug?
|
# ? Mar 1, 2016 17:07 |
|
YeOldeButchere posted:Since 2012 you say...? How likely is it that this bug was introduced by a "fix" for some other leap year bug? Not sure but I found the bug report for it... https://bugs.php.net/bug.php?id=62476
|
# ? Mar 1, 2016 17:12 |
|
YeOldeButchere posted:Since 2012 you say...? How likely is it that this bug was introduced by a "fix" for some other leap year bug? Nope, second comment in the link provided says it was introduced in the change to fix https://bugs.php.net/bug.php?id=51994
|
# ? Mar 1, 2016 17:31 |
|
I have trouble getting upset about ridiculous and weird leap-year bugs. Basically every date library has had them, and the ones that haven't are mostly replacements for previous libraries designed specifically to fix the edge-case bugs of the previous library.
|
# ? Mar 1, 2016 18:24 |
|
You are completely insane if you think conditional expressions are bad for code quality. Just use this style of indents and line breaks:code:
I agree that nesting conditionals is generally bad and does make one want for better pattern matching expressions in the language. code:
|
# ? Mar 1, 2016 19:10 |
|
fleshweasel posted:You are completely insane if you think conditional expressions are bad for code quality. Just use this style of indents and line breaks: The operators can be chained nicely if you place the conditionals in the second branch: code:
|
# ? Mar 1, 2016 19:19 |
|
HappyHippo posted:The operators can be chained nicely if you place the conditionals in the second branch: This, but with a different indentation style to keep the results lined up. code:
|
# ? Mar 1, 2016 19:32 |
|
Maybe C++22 will make switch an expression.
|
# ? Mar 1, 2016 19:36 |
|
Brain Candy posted:If you're worried about that, why bother with all that ornamentation. It was a simple example to make a more general point -- if that code didn't use return-from-all-branches style, it'd be buggy and still compile with that line commented out. I have been leaning on this a lot lately, and it's useful. And there is no good reason to disallow it (if you're returning from both branches -- otherwise, it's deceptive). When shouldn't you use else after return? When you're "early exiting" and the like, sure, like in Subjunctive's example with multiple exits. When it'd get particularly nested and hairy, yeah. When you think it's better not to, okay. Subjunctive posted:Would you reject a patch during code review for not having else-after-return-where-else-is-terminal-and-itself-returns? Generally: No. Because early exits are fine and it's subjective whether it looks like an "early exit" or not, and you're also dancing around, doing more work, hoping that a later modification to the code will benefit, when you might actually benefit more for it to be in early-exit style. But if there is an else after return, it must also return. Subjunctive posted:Maybe C++22 will make switch an expression. Only so you can use it inline in templates. And is C++22 going to be a thing? I assumed it was on a 3-year cycle.
|
# ? Mar 1, 2016 20:28 |
|
bigmandan posted:PHP has a bug (since 2012!) that gives you the incorrect date when it's a leap year depending on the order of the format string. Not only is the behavior wrong, it's consistently wrong even in HHVM.
|
# ? Mar 1, 2016 21:18 |
|
McGlockenshire posted:Not only is the behavior wrong, it's consistently wrong even in HHVM. That's what compatibility means!
|
# ? Mar 1, 2016 21:21 |
|
sarehu posted:What basically we can witness here with these dogmatists is that they take the set of reasonably-written functions, identifies some properties P_1, ..., P_n on them, defines f mapping whether (P_1, ..., P_n) will likely create a reasonably-written function, and then (here comes the ridiculous part) picks a sub-rectangle of f's support that they like, often (because they're bad at thinking) a particularly idiosyncratic one. Also, trying to capture a else-after-return usage from my own code has led me to greater understanding. Thanks, thread I belong in!
|
# ? Mar 1, 2016 21:26 |
|
Edit meh no one seems interested. It is boring code I suppose .
Knyteguy fucked around with this message at 20:43 on Mar 2, 2016 |
# ? Mar 1, 2016 23:59 |
|
bigmandan posted:PHP has a bug (since 2012!) that gives you the incorrect date when it's a leap year depending on the order of the format string. https://twitter.com/recursecenter/status/704429884374958080
|
# ? Mar 3, 2016 01:03 |
|
SupSuper posted:Date parsing you say? That whole thing is basically restating that date string parsing is undefined, and that the API matched that of java.util.Date (by agreement with Sun, sigh).
|
# ? Mar 3, 2016 02:12 |
|
JawnV6 posted:What part of "every case has to have a break" is ambiguous enough for you to go stuffing returns in there? It's one thing to look at the rules and try to think of clever ways around them, tossing them out entirely then claiming victory seems kinda hollow. I meant, every possible option has to be defined, you cannot have special case 1 and then everything else
|
# ? Mar 3, 2016 08:29 |
|
SupSuper posted:Date parsing you say? "Doctor, doctor, it hurts when I invoke unspecified behaviour" "Then don't do that"
|
# ? Mar 3, 2016 13:05 |
|
qntm posted:"Doctor, doctor, it hurts when I invoke unspecified behaviour" "But I have a business requirement"
|
# ? Mar 3, 2016 17:21 |
|
Munkeymon posted:"But I have a business requirement" Then satisfy it with your own code, rather than the platform's.
|
# ? Mar 3, 2016 18:20 |
|
No business requirement on Earth compels you to use new Date(str). Use moment.js. Hell, parse the string by hand. E: but don't use moment(str) which apparently falls back to new Date(str). Yikes.
|
# ? Mar 3, 2016 18:24 |
|
Edison was a dick posted:Then satisfy it with your own code, rather than the platform's. Well yeah - I was just trying to extend the joke. But then... qntm posted:E: but don't use moment(str) which apparently falls back to new Date(str). Yikes. lol
|
# ? Mar 3, 2016 19:04 |
|
qntm posted:E: but don't use moment(str) which apparently falls back to new Date(str). Yikes. This poo poo right here has already bitten me in the rear end.
|
# ? Mar 3, 2016 19:12 |
|
Bognar posted:This poo poo right here has already bitten me in the rear end.
|
# ? Mar 3, 2016 19:54 |
|
qntm posted:E: but don't use moment(str) which apparently falls back to new Date(str). Yikes. At least it now gives you a big warning message in the dev console if you use it like that.
|
# ? Mar 3, 2016 22:26 |
|
Ochowie posted:At least it now gives you a big warning message in the dev console if you use it like that. Like anyone ever pays attention to warnings. I wish I was kidding. Edit: I am starting to question the usefulness of code quality / security tools. For every actual issue they catch, invariably they seem to be setup to catch 100 things that are not an issue, but have to be at the same priority as a real issue. I have just spent 8 hours copy pasting notes about log forging not being an issue for all the log statements we added this version. This is due to the underlying framework doing it for us. Logs are the only way we can identify many production issues. HFX fucked around with this message at 08:09 on Mar 4, 2016 |
# ? Mar 4, 2016 07:58 |
|
HFX posted:Like anyone ever pays attention to warnings. I wish I was kidding. Use better tools, I guess. If you introduce a new warning in our code base you need to give a reason for it at commit time (or the commit is rejected), it shows up in the diff review tool, and there are straightforward ways to suppress specific warnings in the source itself. False positives are considered high-priority bugs in the checker.
|
# ? Mar 4, 2016 08:09 |
|
Subjunctive posted:Use better tools, I guess. If you introduce a new warning in our code base you need to give a reason for it at commit time (or the commit is rejected), it shows up in the diff review tool, and there are straightforward ways to suppress specific warnings in the source itself. False positives are considered high-priority bugs in the checker. Also, those kinds of tools are usually configurable; don't turn on the warnings you don't agree with. If you are coming from a code base riddled with warnings, you should definately turn most of them off until you can get buy in from people that Warnings Are Bad And Should Be Immediately Addressed. Boil the frog slowly. Otherwise you're just generating graphs to sigh at.
|
# ? Mar 4, 2016 14:14 |
|
Brain Candy posted:Also, those kinds of tools are usually configurable; don't turn on the warnings you don't agree with. Or set your tools up so that they only block for new warnings added by the diff in question, to start.
|
# ? Mar 4, 2016 14:29 |
|
HFX posted:Like anyone ever pays attention to warnings. I wish I was kidding. I know you're not kidding. However, it did help me when I was bumbling around with it for the first time so there's that.
|
# ? Mar 4, 2016 18:25 |
|
Recently a friend of mine brought up that he's found ℃ in some content for the website we're making. Why... why is that a single character? And (something that I've found) - why the distinction for pi as: π, 𝛑, 𝜋, 𝝅, 𝝿 and 𝞹 I don't know though if א (hebrew letter) and ℵ (mathematical symbol) that differ only by RTL/LTR is a horror though.
|
# ? Mar 4, 2016 19:10 |
|
you never know when pi might be a vector
|
# ? Mar 4, 2016 19:13 |
|
canis minor posted:Recently a friend of mine brought up that he's found ℃ in some content for the website we're making. Why... why is that a single character? And (something that I've found) - why the distinction for pi as: π, 𝛑, 𝜋, 𝝅, 𝝿 and 𝞹 For pi: http://www.unicode.org/versions/Unicode8.0.0/ch22.pdf quote:Semantic Distinctions. Mathematical notation requires a number of Latin and Greek alphabets that initially appear to be mere font variations of one another. The letter H can appear as plain or upright (H), bold (H), italic (H), as well as script, Fraktur, and other styles. However, in any given document, these characters have distinct, and usually unrelated, mathematical semantics. For example, a normal H represents a different variable from a bold H, and so on. If these attributes are dropped in plain text, the distinctions are lost and the meaning of the text is altered. Distinguishing letters of a particular script (like hebrew) versus their mathematical equivalents also makes sense. Not every font is going to define every single unicode character. If someone is making a font with emphasis on mathematical symbols it would be nice to know that you just have to cover the "symbols" section of the unicode standard, not some random set of characters from a bunch of different languages. It's also helpful for the users - if you're writing math limit yourself to the symbols, don't grab random characters out of hebrew, because not every font is going to cover every script you borrow from, and even if they do it may not be stylistically consistent. HappyHippo fucked around with this message at 19:27 on Mar 4, 2016 |
# ? Mar 4, 2016 19:21 |
|
canis minor posted:Recently a friend of mine brought up that he's found ℃ in some content for the website we're making. Why... why is that a single character? For purposes of roundtrip compatibility with older character sets that included that character.
|
# ? Mar 4, 2016 19:46 |
|
Whenever it's Unicode the answer is always old white men hate Asians.
|
# ? Mar 4, 2016 20:01 |
|
FamDav posted:Whenever it's Unicode the answer is always old white men hate Asians. loving neo-colonialist euros demonstrating their disrespect for the ancient cultures of the east by ... going out of their way to make sure unicode supports round-trip conversions with every bad decision ever made in the dbcs era?
|
# ? Mar 4, 2016 20:07 |
|
|
# ? Jun 8, 2024 05:41 |
|
HappyHippo posted:Distinguishing letters of a particular script (like hebrew) versus their mathematical equivalents also makes sense. Not every font is going to define every single unicode character. If someone is making a font with emphasis on mathematical symbols it would be nice to know that you just have to cover the "symbols" section of the unicode standard, not some random set of characters from a bunch of different languages. It's also helpful for the users - if you're writing math limit yourself to the symbols, don't grab random characters out of hebrew, because not every font is going to cover every script you borrow from, and even if they do it may not be stylistically consistent. I agree that such distinction makes sense for alephs, but for pi it is still a mystery for me. I don't think there's a distinction (in meaning) between MATHEMATICAL ITALIC SMALL PI and MATHEMATICAL BOLD SMALL PI, but to me this should be a singular character (MATHEMATICAL SMALL PI) that's handled by font transformation, instead of by encoding. Unless we're talking here about times, when font transformations weren't there yet? Hammerite posted:For purposes of roundtrip compatibility with older character sets that included that character. Are there any resources on this I can read explaining "why"? I'd have thought that even if a character set had Ⅻ as one singular character, translating it to Unicode should have become XII. If translating XII from Unicode to that character set, it would go back to Ⅻ, but I guess it's naive of me to think so (or I guess there's a roman sentence where IV should stay IV instead of Ⅳ) edit: I wonder - in a hebrew text talking about magnitudes of infinity, wouldn't a single aleph be used either way? edit2: Why characters don't have a property that disallows them from being used - so, fine - ℃ is still used, and is compatible, but if you decide to write something, it really should be °C canis minor fucked around with this message at 20:45 on Mar 4, 2016 |
# ? Mar 4, 2016 20:09 |