|
Ithaqua posted:There's nothing confusing about it, it's just less readable, and the second you start stacking them it turns into a mess. I submit for your consideration: http://stackoverflow.com/questions/9101719/im-looking-for-a-free-tool-stand-alone-or-add-in-that-can-decompose-ternary-ex/ I think other people here are defending the practice of nesting a further conditional expression as the third operand (if-false-value) of a conditional expression, not embedding further conditional expressions as operands of a conditional expression in full generality. Although it would be possible to write reasonable code doing so, if you don't take it to an insane extreme, and you guide the reader using visual cues like indentation. code:
shrughes posted:It's because some people are afraid of functional programming. I don't understand what this has to do with functional programming.
|
# ? Sep 24, 2012 20:19 |
|
|
# ? May 27, 2024 18:20 |
|
Hammerite posted:
See, I hate that. That takes me way longer to parse than if it were just written out with ifs and elses. I don't think it's a horror to do it that way, I just don't like it personally, and I'd probably change it if I ran across it in code I was working on.
|
# ? Sep 24, 2012 20:27 |
|
Hammerite posted:
That's different. I hate the nested case. The original case is not nested at all.
|
# ? Sep 24, 2012 20:43 |
|
Suspicious Dish posted:That's different. I hate the nested case. The original case is not nested at all. I don't understand what you are talking about when you refer to "the nested case" and "the original case". What do you hate?
|
# ? Sep 24, 2012 20:52 |
|
Hammerite posted:I don't understand what you are talking about when you refer to "the nested case" and "the original case". What do you hate? See, we're having trouble even telling the different cases apart!
|
# ? Sep 24, 2012 21:01 |
|
Hammerite posted:I don't understand what you are talking about when you refer to "the nested case" and "the original case". What do you hate? I originally had a bigger example, but removed it because I thought you guys would just be annoyed by the noise. JavaScript code:
JavaScript code:
|
# ? Sep 24, 2012 21:12 |
|
Hammerite posted:I don't understand what you are talking about when you refer to "the nested case" and "the original case". What do you hate? darthbob88 fucked around with this message at 21:16 on Sep 24, 2012 |
# ? Sep 24, 2012 21:13 |
|
I did this once C++ code:
|
# ? Sep 24, 2012 21:16 |
|
Good, because you don't need to. It's perfectly readable and understandable, once you sit down and read it, and would be even easier to understand inside an IDE with paren matching. The descriptive function names are amazingly clear.
|
# ? Sep 24, 2012 21:22 |
|
Suspicious Dish posted:Can you identify which one is the nested case, and which one is the original case? I am not sure what relevance your example has to mine, since the indentation pattern in your example is dissimilar. Your example: JavaScript code:
JavaScript code:
|
# ? Sep 24, 2012 21:31 |
|
Because they're the exact same code, indentation different or not. (I meant to copy your indentation style; I copy/pasted the code and changed around a few variable names without thinking about indentation). Can you still not identify which one is nested?
|
# ? Sep 24, 2012 21:43 |
|
McGlockenshire posted:Good, because you don't need to. It's perfectly readable and understandable, once you sit down and read it, and would be even easier to understand inside an IDE with paren matching. The descriptive function names are amazingly clear. C code:
|
# ? Sep 24, 2012 21:43 |
|
GrumpyDoctor posted:I did this once You are an amateur in the business of writing bad code, my friend, and I am a professional. PHP code:
Suspicious Dish posted:Because they're the exact same code, indentation different or not. (I meant to copy your indentation style; I copy/pasted the code and changed around a few variable names without thinking about indentation). Can you still not identify which one is nested? I thought that your argument was that it was hard to tell them apart. I think I'm still not understanding your point. For me, it is ok to nest conditional expressions up to a very limited level of complexity, but the reader should be helped by formatting the expression to make its structure easy to perceive.
|
# ? Sep 24, 2012 21:53 |
|
Suspicious Dish posted:
The comment is perfectly correct but yes, this weird idiosyncrasy is probably the one reason it might qualify as a horror (still pretty mild, though).
|
# ? Sep 24, 2012 22:53 |
Hammerite posted:You are an amateur in the business of writing bad code, my friend, and I am a professional. Hammerite posted:I thought that your argument was that it was hard to tell them apart. I think I'm still not understanding your point. For me, it is ok to nest conditional expressions up to a very limited level of complexity, but the reader should be helped by formatting the expression to make its structure easy to perceive. A nested ternary expression as the second operand to a ternary removes the immediate consequence of a false condition much further from the condition, while when you only nest on the third operand the immediate consequences of both possibilities are easily visible. I would certainly prefer reading this (change indentation to your preference): C++ code:
C++ code:
|
|
# ? Sep 24, 2012 22:57 |
|
Hammerite posted:I don't understand what this has to do with functional programming. The alternatives that people provide imply some form of mutation, whereas the ternary form is a non-mutating operation. It's the reason why you often use the ternary operator to initialize a const object or when doing branching at compile-time in C or C++.
|
# ? Sep 24, 2012 23:03 |
qntm posted:This is only a horror if you try it in PHP. Maybe this one counts as a horror: ourDiv.removeClass().addClass(((ourIndex%3+1) % 3 ? ((ourIndex%3+1) % 2 ? "chartOptionsLeft":"chartOptionsCenter") : "chartOptionsRight")).attr("id", "chartOption" + ourIndex).attr('name', ourIndex); I'm pretty much straight-up abusing ?:, here, because it's fun to use. I could have just used a loop counter (or a dozen other methods) to determine whether the item should be left, center, or right, but what fun is that? I also loaded it down with mod operators just because.
|
|
# ? Sep 24, 2012 23:26 |
|
Suspicious Dish posted:
There's no logical implication operator in C++, but fortunately you can emulate one!
|
# ? Sep 24, 2012 23:30 |
|
GrumpyDoctor posted:There's no logical implication operator in C++, but fortunately you can emulate one! I've used this idiom a lot in SQL. I'm glad I'm not the only one who wants implies to be part of the standard set of logical operations.
|
# ? Sep 25, 2012 00:31 |
|
Zombywuf posted:I've used this idiom a lot in SQL. I'm glad I'm not the only one who wants implies to be part of the standard set of logical operations. EDIT: Zombywuf posted:No. It only takes its lhs as an argument. PrBacterio fucked around with this message at 00:52 on Sep 25, 2012 |
# ? Sep 25, 2012 00:41 |
|
PrBacterio posted:Now you've made me think about if it would be possible to overload the '->' operator in C++ to function as a logical implication operator No. It only takes its lhs as an argument.
|
# ? Sep 25, 2012 00:45 |
|
Zombywuf posted:No. It only takes its lhs as an argument. ->* is a binary operator :}
|
# ? Sep 25, 2012 00:47 |
|
=> I forget, is that actually an operator? Or are we stuck with >=
|
# ? Sep 25, 2012 01:07 |
|
Suspicious Dish posted:=> No, it's not. But, you could always do <= and have the implication go right to left instead of left to right.
|
# ? Sep 25, 2012 01:08 |
|
Suspicious Dish posted:=> EDIT: More realistically speaking though, it probably would be easiest to just use /implies/ as the operator. PrBacterio fucked around with this message at 01:17 on Sep 25, 2012 |
# ? Sep 25, 2012 01:09 |
|
Suspicious Dish posted:=> => isn't an operator. edit: oh, you were talking specifically about c/++. This is a pointless post.
|
# ? Sep 25, 2012 01:09 |
|
Oh yeah, you can't overload anything that only takes primitive types as arguments (i.e. bool) as well.
|
# ? Sep 25, 2012 14:45 |
|
C++ code:
|
# ? Sep 25, 2012 16:17 |
|
Whoops. Swing and a miss.
Floor is lava fucked around with this message at 17:36 on Sep 25, 2012 |
# ? Sep 25, 2012 17:31 |
|
code:
|
# ? Sep 25, 2012 17:42 |
|
Zombywuf posted:Oh yeah, you can't overload anything that only takes primitive types as arguments (i.e. bool) as well. Yeah, but you can get around this by just wrapping your arguments. _( implication_goes_here ) <= some_bool && some_other_bool You'd want the implication_goes_here part to be a function object, though, so that you get lazy evaluation.
|
# ? Sep 25, 2012 18:15 |
|
That Turkey Story posted:Yeah, but you can get around this by just wrapping your arguments. Think I prefer PrBacterio's solution.
|
# ? Sep 25, 2012 18:57 |
|
Zombywuf posted:Think I prefer PrBacterio's solution. I think I prefer neither of them, and you should too.
|
# ? Sep 25, 2012 19:03 |
|
When a coding error becomes a coding horror: Added a line to my PHP to spawn a new instance of itself, due to inherited weirdness. But it wasn't dying right and kept spawning new processes. In my attempt at killing them, I ran an untested command to kill all of my processes. Except I hosed it up and apparently killed everything *except* my processes, which meant I killed our production server. edit: and yes I know the real horror is doing development work on the production machine. Golbez fucked around with this message at 20:27 on Sep 25, 2012 |
# ? Sep 25, 2012 20:22 |
|
quote:The range of character sequences expected should be strictly enforced by the javascript on the front end and the code on the backend. Any submission with unexpected characters or the < and > and ` characters should be rejected, before it could be used in any kind of database query. Don't send the submitted data back to the browser though, just report to the user that unexpected characters were detected. Odd character sequences like '1 AND 1', 'CREATE TABLE' and 'DROP TABLE' and 'SELECT *' should be filtered against. Multiple adjacent spaces should be collapsed into one before the filtering. Numbers should be checked to make sure they are in the range expected. On some of the sites I've made, if the backend code detects any kind of SQL injection attack, it logs the ip address and automatically blocks that ip address for a few hours, in case its a script kiddy attack that is going to send a billion requests in an hour trying all kinds of attacks.
|
# ? Sep 25, 2012 22:29 |
|
quote:And I think that mysql_real_escape_string is deprecated. I think its just mysql_escape_string now. I hope, for your sake, that you don't work with the person who said that.
|
# ? Sep 25, 2012 22:34 |
|
Poe's Law definitely seems to apply to that.
|
# ? Sep 25, 2012 22:44 |
|
Sounds quite straightforward really. All you have to do is filter against odd character sequences.
|
# ? Sep 25, 2012 22:50 |
|
Hammerite posted:Stuff about filtering My "site" actually does some filtering against typical script-kiddie attacks (usually obvious identifiers for them), and adds the requester to a block list that lasts for a few hours, just to make those scripts not actually cause much load on the server while they fire their 10-per-second requests off. The rest of it is just pure bullshit though. Proper escaping (or just using a real database object and avoid manual queries as much as is feasible will prevent that poo poo.
|
# ? Sep 26, 2012 00:06 |
|
|
# ? May 27, 2024 18:20 |
|
Whenever I'm facing a registration form that has a bunch of arbitrary tax code validations for the password written on the side, I have visions of a garden variety IT know-it-all going into soapbox mode with more or less those same words.
|
# ? Sep 26, 2012 00:33 |