| « Prev | Page 1 | Page 2 | Page 3 | Next » |
Re: Divide and Validate
2013-01-07 13:56
•
by
instigator
(unregistered)
|
|
I'm guessing there is a validation check server side as well. But doing it on the client side saves a potential network traversal, server load, etc. This would be particularly advantageous if you are doing live validation.
|
Re: Divide and Validate
2013-01-07 13:57
•
by
Berend
(unregistered)
|
|
Nah, I was talking about the function declaration which should be
var proFormComplete = function(){...} but of course it could be part of a larger function like you suggested. |
Take two seconds on Google to research it. |
Re: Divide and Validate
2013-01-07 14:04
•
by
d.k.ALlen
(unregistered)
|
Relying on Google for judging the sanity of operator overloading is the real WTF. |
Re: Divide and Validate
2013-01-07 14:13
•
by
eVil
(unregistered)
|
You made the assertion, so the onus is on you to provide evidence when challenged. Demanding that other people google something to prove your point is both lazy and foolish. |
|
Trying to post that shit on a phone on a very wobbly train is TRWTF.
|
|
TRWTF is posting as different users :facepalm:
|
|
Indeed. Still you should really explain yourself if you want people to agree... Hardly anyone ever googles someone elses side of the argument.
|
|
I like to think that if anyone ever asked me for a function that reported what percentage of a form was filled out correctly, I would write something a lot like this. Probably not as clear, though.
WTF specifications deserve WTF code. -Harrow. |
Re: Divide and Validate
2013-01-07 15:15
•
by
Capitalist
(unregistered)
|
You said it already. Seriously, in weakly-typed languages, there is possible confusing with addition (when the strings can be converted to numbers). In strongly-typed languages, there is no problem. C++, Pascal and others have been doing it for decades. |
Re: Divide and Validate
2013-01-07 15:18
•
by
Capitalist
(unregistered)
|
That's what I assumed on first reading. Of course it's not very obvious. When supported (C++, C99, etc.) I'd use an explicit cast to bool, otherwise (C90 and older) I might use "!!foo", which is also not obvious the first time, but at least is a more or less common idiom used for no other purpose (unlike "&& true" which may be left over from a check removed, or a placeholder for a check to be added ...). |
Re: Divide and Validate
2013-01-07 15:27
•
by
Capitalist
(unregistered)
|
1. Maybe, though I don't think it's demaning too much for other programmers to know some basic rules of their language, including ordinal values of booleans (if they're well-defined in the given language). 2. At least that. Though, as others have pointed out, that kind of return value doesn't even give the caller a reliable way to check whether everything is valid (comparing against 100 is not always reliable), and a percentage is not very useful to the end-user either. So just the number of valid fields (and porobably the number of total fields, since this function is where the knowledge is how many fields there are to be validated). 3. Programmers don't read comments. A self-explanatory variable name like "total_validation_fields" stands a slightly better chance to be noticed and maintained. If you expect maintenance often, maybe something like this, so copying/pasting a line of the validation code will keep track of the total:
|
Re: Divide and Validate
2013-01-07 15:53
•
by
F
(unregistered)
|
Why only "might"? |
|
I like that it considers 1-character résumés valid.
|
Re: Divide and Validate
2013-01-07 16:27
•
by
¯\(°_o)/¯ I DUNNO LOL
(unregistered)
|
Then I guess you don't know that dates back to the late '70s, when computers didn't even have enough RAM to contain this web page you're reading right now. |
I think you misunderstand me. I mean in addition to the ampersand operator. It would be like C# having both the plus sign and ampersand available for string concatenation. |
Re: Divide and Validate
2013-01-07 17:29
•
by
luolimao
(unregistered)
|
That last line should be return 100*ct/(props.length+1) But as someone else mentioned, TRWTF is % completion. |
Re: Divide and Validate
2013-01-07 17:37
•
by
Billy G
(unregistered)
|
This was my first reaction 2 - forget the rest of it, what's the purpose of the "&& true"? Or is the problem that u.employerSharing might be any odd number (I think it would have to be odd.....) But yeah, as others have said, TRWTF is Javascript |
Re: Divide and Validate
2013-01-07 17:49
•
by
Holly Molly
(unregistered)
|
No, No, no. C happened not to have a boolean, so people would use integers as booleans, however going the other way (and making an int from a boolean) is impossible, because the boolean type does not exist. The biggest problem with using the same integers we use as a boolean in C as integers is that true can be multiple values. The way C uses an integer in a boolean expression equates to something like:
What is the value of true? On many compilers, it's 1. More intuitively, it should probably be 0xff. But it can actually be a whole heap of things.
which on my compiler prints: 3 0 3 C does not have a (standard) boolean type, so coercing back to an integer isn't really coercing - it's using an integer for what it's meant for. That said, it is often dangerous to use an integer simultaneously in logical and arithmetic expressions (although I'll confess I do it to check pointers are non-null).... |
Re: Divide and Validate
2013-01-07 17:55
•
by
Holly Molly
(unregistered)
|
OK - I stand corrected, I didn't know about _Bool, but bool gives me an "error: 'bool' undeclared", (both on gcc and it's windows friend mingw) In that case maybe people do coerce _Bool to int....I don't really think it's a very smart (or necessary) thing to do, but there ya go..... |
Re: Divide and Validate
2013-01-07 18:03
•
by
Simon
(unregistered)
|
Java does, yes. But this is javascript, a completely different beast. |
|
Whenever I write a piece of code, and I'm pleased with how clever it is; I rewrite it to be simpler.
|
Re: Divide and Validate
2013-01-07 18:13
•
by
gwhe ir
(unregistered)
|
Children, please. Who gives a rat's left testicle.... |
Re: Divide and Validate
2013-01-07 18:19
•
by
mick
(unregistered)
|
Why is everyone obsessed with %complete??? It's like those stupid progress bars that get slower and quicker. Is a field with no name equivalent to a field with no age (I have several letters in my name, and will probably never reach 3 digits in age). I sort of understand the "you have filled in 7 of 9 fields", but isn't it perhaps more useful to say "You need to put a name and surname in you fuckstick" - the user doesn't give a shit about random numbers relating to the form, they just wanna know why it keeps getting rejected. |
|
Using http://www.codinghorror.com/blog/2008/07/spartan-programming.html spartan coding you should inline the local variable ct. That is all.
|
Re: Divide and Validate
2013-01-07 18:47
•
by
foo
(unregistered)
|
C (before C99) did not have a Boolean type, but well-defined Boolean values, 0 and 1. Each Boolean operator (&&, ||, !) returns 0 or 1. Not on "many compilers", but on all correct compilers. Certainly not 0xff, since the size of int is not specified, but usually larger than 8 bits (or 9 bits signed ;-). Also, I'd argue that 1 is more useful, since it can be used for counting (as in today's example -- that is not the WTF about it), whereas 0xff, -1 or any other value has little practical advantage. Your example uses just ints, so the results are what they are with ints, no surprise. The two places you use the value of x in Boolean contexts (if, !) don't change the value stored in x (why would they?), so of course total = x = 3. |
Re: Divide and Validate
2013-01-07 19:39
•
by
Amakudari
(unregistered)
|
|
Not even smart. For x && true, if x is falsy then it evaluates to x without an implicit cast.
The only case in which it "works" is if employerSharing can be false or truthy, which is chaotic evil. So in the remaining sane case, where employerSharing can only be false or true, the && true is just redundant and potentially confusing. |
Re: Divide and Validate
2013-01-07 23:39
•
by
old timer
(unregistered)
|
The Bool type was only introduced in C99. And even now, it is defined as an integer type. I don't think that the idea of "coercing booleans to integers" comes from C... In spite of the obvious differences, the code is clear and intuitive in BASIC. Because BASIC did not have seperate logical and arithmetic operators, all boolean operations were arithmetic operations. That is why, unlike FORTRAN, BASIC evaluates all terms in a boolean/arithmetic expression, and that is why, unlike C, !0 = -1. This leads me to suspect that the original author had strong experience with some version of BASIC. To an experienced programmer, the code is obvious. To a C programmer, as indicated in the discussion, not so much. |
You can if you use strings and property indexing:
|
Re: Divide and Validate
2013-01-08 03:55
•
by
gallier2
(unregistered)
|
You have to include stdbool.h to have the bool alias (required by the standard). |
|
Wow, let's build our own int, so we won't mix types:
function getInt( n ) {
Now we only need to add floating point arithmetics ... |
Re: Divide and Validate
2013-01-08 06:00
•
by
John
(unregistered)
|
|
Looks like someone didn't get the memo about readable code.
|
|
Booleans are assimiled to int since ages, just look at power switch (1/0) or in electronic, the way a line with no signal which maps to a false has 0v. Bools also works as integers: commutative, transitive, etc if you map && to * and || to + mapping anything greater then 1 to 1 to stay within the boolean values. In fact a bool is just a bit 1 or 0 or in C a word (8, 16, 32 or 64 bits) artificially limited to 1 bit.
For the implementation of the function, that's where I would use a map and a reduce (https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/map https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/reduce) |
Re: Divide and Validate
2013-01-08 07:52
•
by
Geoff
(unregistered)
|
|
Accuracy and precision requirements very with use. I doubt there is a problem here. Its a display value to give the user some idea how much more agony they have ahead filling out answers to questions that at least to them and quite likely in general are asinine to their purpose.
Yes 101% will look stupid but you won't show them that, when proFormComplete >= 100 you will simply move on to the next application screen. The rest of the time users won't know or care if you display 48% complete when its really 47% or whatever. |
Re: Divide and Validate
2013-01-08 07:54
•
by
F
(unregistered)
|
Clearly you've never had to develop anything at the behest of a "marketing" department who, by definition, know what the customer / end-user wants. |
Re: Divide and Validate - live or die by your code
2013-01-08 08:11
•
by
jEDI
(unregistered)
|
|
Maybe every one should be made to put up the code they would use, in their choice of language, before their comment. Then we could all safely ignore the rest of the comment if the code is obviously pants. That certainly would have saved me the time it took to read Capitalist's comment.
|
|
TRWTF is actually requiring linkedin for application ...
|
Re: Divide and Validate
2013-01-08 10:14
•
by
gnasher729
(unregistered)
|
The problem is: I don't know if your remark is sarcastic or stupid. Let's just say that the form will never be 100% filled with that change. |
It shouldn't be assumed in a digital circuit that voltage high is 'true' and voltage low is 'false'. |
|
why .09, why not .10
|
Or, for that matter, vice versa. Some circuits go as far as toggling the voltage level on one line for 1 and another for 0. Really. Hardware designers are crazy… |
Whenever I write a piece of code, and I'm pleased with how clever it is; I write a large paragraph above it explaining what it does. |
Because you are only validating against 9 fields. The math works like this: Number_of_fields_good / Total_Number_of_fields = %percentage of fields complete. So (for an example) 8 validated fields out of 9 would return .88(8888etc), which multiplied by 100, will return 88(.88+), which can be used as a percentage. What this particular developer here instead of multiplying by 100, was use the inverse; he divided the number of fields by 100, and then divided the total number of valid fields (8 in our example: 8/.09=88.88+) so that he would get 88.88+% without needing to do any more math. Then he runs ciel (rounds up to the nearest whole number) yielding 89%. |
Re: Divide and Validate
2013-01-08 14:30
•
by
Tasty
(unregistered)
|
When I define my next language, I'm making TRUE coerce to imaginary I. Then, it will never be less or more than anything. |
|
I think it should be a little clever-er, so it can be like installation progress bars. You know, you fill in one field, "9% done!" Fill in two fields "18% done!" Fill in three fields "18% done!" Fill in four fields "18% done!" Fill in five fields "1% done!" Fill in six fields "98% done!" ...
|
Re: Divide and Validate - live or die by your code
2013-01-08 15:34
•
by
Capitalist
(unregistered)
|
How typical of you pussy programmers! Guys like you always talk about maintainability, but when someone proposes a solution that is actually maintainable (add a field: copy/paste one line and you get both counts correct), you get shocked when it doesn't conform to what you know. Two statements on a single line? Hell, how dare he! Seen it all too often. So next time, don't talk about maintainability, talk about not wanting to learn anything new because it bends your little mind. |
Re: Divide and Validate
2013-01-08 16:34
•
by
leo
(unregistered)
|
|
To me, transforming 100*ct/9 to ct/0.09 is what makes this snippet to go from "meh, not wtf" to "wtf is that dark magic ?" because you cannot tell easily what the programmer is trying to achieve.
Of course using a comment or a descriptive name could have done it, ut neither of them can be found, so in my book this classifies as bad code. From this snippet this may not seem obvious, but the person that thinks it is better to write 0.09 than 9/100 is probably the same one that gave you this clusterfuck of code that reverses a matrix in 3 undecipherable lines but is not efficient at it and suffers a bug your boss asked you to remove. |
Re: Divide and Validate
2013-01-09 03:38
•
by
JimFin
(unregistered)
|
Well, saying it's validation while it's percentage calculation combined with the fact that the actual percentage calculation is hidden is somewhat a WTF. Here you can find some WTFs that are not really WTFs but they are misunderstandings. When WTF is said not to be WTF, it should be a big red flashing <marquee> warning: some day you will miss a WTF that you made yourself and you will make your coworkers very angry. |
Re: Divide and Validate
2013-01-09 17:54
•
by
Scripticious
(unregistered)
|
Nice work, and completely correct. It's amazing that so many others missed this. To give those here who continue to claim that the code is well written some food for thought, here's a simpler example: [10:44:25.966] 1 + 2 + 3 + ("" && true) + 4 [10:44:25.968] "64" Javascript has a nuance that other languages don't with regards to boolean operations: they will always return either the first falsy or last truthy operand in the statement - NOT necessarily a boolean. This is an extremely powerful feature and allows developers to create short and sweet validation statements. For example: var firstSurname = (isMarried && maidenName) || currentSurname; The above is rather a variation on a ternary expression, but you can see the potential for reducing many complex validation tasks down into a single simple step. |
|
Why do you think a TDWTF submission can have only one "the real WTF"? This one is a minor cornucopia of WTF.
As hinted elsewhere, the overall WTF is that you CAN write code like this, and it works (insert frown 'smiley' here). If you want to identify the specific "real WTF", it's that apparently, u.employerSharing must be True to be valid. Another WTF, only hinted at, is why check the type of the variables? I don't mean because non-checkboxes will be strings. I mean the type is not a user input. An error there would be a program error (i.e. BUG), not an data validation issue. Why was "&&true" included with u.employerSharing you ask? Programmer OCD, obviously. All the other fields have 2 conditions tested. And lastly, regarding math on strings, in Perl you can't do true math on non-numeric strings, but you can do incrementing (++) on alpha-numeric strings, with results like "AA"++ = "AB" and "AZ"++ = "BA". |
| « Prev | Page 1 | Page 2 | Page 3 | Next » |