- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
The obfuscation thing smells of someone trying to write the old barf-worthy C thing:
to avoid problems caused by writing
=instead of==.But forgetting two things: assigning to the result of
length()doesn't work anyway, and Java compares objects with.equals(...), so it counts as first-stripe cargo cult.Admin
Languages which auto allow cases in switch statements to fall to the next case are evil. It's far too easy to forget one, especially in a rare condition, that is never caught in testing until the customer manages to trigger it. Swift and Kotlin (when) do this the right way, for example. I also see no reason today to use Java instead of Kotlin.
Admin
What would be the best way to un-WTF this? Intuitively I would use exceptions for error management in place of switch/case and put that in a separate function; what would TDWTF reader do?
Admin
I disagree. There is nothing bad about giving the developer more tools and more power. The only evil is removing tools and powers from a developer just to prevent him making mistakes.
Might as well make a surgeon work with plastic toy knifes for fear of having him cut the wrong thing.
Admin
I want to say yes, but on reading the code a little further, it looks like the purpose of this section is to deal with some kind of job-dependency system they have in place. This might actually get called in a completely different thread, and is intended to be generic with respect to the job's internals.
I'm of the mind that if something fails, all of its dependents should just be cancelled (or put in some other indefinitely-blocked state until the parent runs successfully), but if we give them the benefit of the doubt and assume that everything going on is required... I'm not sure what I'd do better, aside from breaking up the code and rewriting it to be clearer.
I've actually written job systems several times at my current job (my superiors insist on delivering machine learning models via REST API...) and I've done it wrong a few times, but I have no idea how you'd get here.
Admin
Good god, man! They actually codified the design chatter.
''' SomeEntity someEntity = service.get(job.getSomeEntityId()); if (!someEntity.getStateReference().getLocationReference().getLocationTypeReference() .getName().equals(Constants.SOME_CONSTATNT)) { // Set Job and then break break; } '''
Admin
if (new Integer(1).equals(job.getSource().getLength())) {
This is reasonable if job.getSource().getLength() can be null, and who knows what type job.getSource() is. (But it should use Integer.valueOf(1)).
Something to note is that Java switches will throw a NullPointerException if the argument is null, so the only way this code will function is if "reason" is non-null even for states NEW, WAITING, or STARTED.
I suspect this code has been mangled during heavy anonymization, though.
Admin
Classic object hierarchy shoehorned into case statement. And yes, OO is still useful in many cases, though it's shunned everywhere.
Admin
No-one is going to mention how awful ERROR_OTHER_5 and friends are as names ?
Admin
Without case fallthrough,no Duff's Device (compilers in those days didn't unroll loops)
(I still look at it once a decade, going "nope, still not legal C". dmr says it is, I don't care :-))
Admin
It's so hard to tell what has been anonymized and what is original. Actually, it probably makes everything far more readable when it's anonymized, because it tightens it up.
Also, I tend to agree that a "fallthrough" command should be required instead of a "break" command, although I can see how in previous days' standards, they were used to labels and goto statements.
Admin
But surgeons use a very specialised and limited set of tools. They don't use meat cleavers and machetes, for example.
Admin
Exactly. Surgeons use the finest of cutting tools, specifically designed for the task at hand. I did hear about a story from Russia recently where a hospital's budget was swindled due to corruption and the doctor bought a handyman drill to screw/ drill something in a patient's skull. But then again, that's Russia we're talking about.
Admin
Most power tools have safety features to prevent you accidentally chopping bits of yourself off. I think it would be better if they required a statement for each case, which is either a break or some other keyword which says to fall through. That way the code is clear about what happens for each case, and there's no accidents.
Admin
I could get behind a fallthrough statment. It's a bit of unnessecary verbosity but it beats not having the tool to begin with.
Admin
Another problem with falling through with or without a special keyword is variable scoping. I don't remember what happens in Java but in C#, falling through is not allowed, and variables in one case cannot be accessed from another, but variable names do conflict between case statements. The solution is to create a block using {}. But, that's a terrible mistake they made. If C# doesn't allow falling through, why not just treat each case as a block?
Admin
Because even great minds some times act like complete morons.
Seriously, who ever thought up the idea of having the switch statment not demand a block surrounded by { } like everything else in the entire language should have his head examined with a set of power tools and the aid of a very determined woodpecker.
Admin
"he most obtuse way to express this idea".... Overly obtuse, yes... but the "most"....here, hold my coffee....
Admin
"Languages which auto allow cases in switch statements to fall to the next case are evil. It's far too easy to forget one, especially in a rare condition, that is never caught in testing until the customer manages to trigger it." Don't blame the language. If your tests don't take every branch, you are not testing correctly. I have often forgotten the "break", but always found this error soon in testing.
The switch ... break construct allows applying the same code to several cases. This example used that a lot, and I have sometimes used "case 1" with a little code and no break, to fall through into "case 2" with the rest of the code.
But I agree that a "fallthrough" statement would be better. It's not only that it avoids the "forgot the break" error, but I think it would make the code clearer.
switch(x) { case 1: case 2: ...code... break; .... }
When I read this, I first think the code for case 1 was forgotten, until I reread it and realize that 1 and 2 were intended to run the same code. This slows down checking the software, every time. A "fallthrough" after "case 1" would make it clear that this was intentional. Also, "fallthrough" is more likely to be prominently located (often right after the "case"), while "break" is almost always buried at the bottom of the code. Even if both are buried, "fallthrough" will be noticed more than the absence of "break", since it is usually exceptional .
Admin
yes, C# disallows implicit fallthough (by absence of a break statement) but there is still the possibility of "explicit fall through" by writing "goto case xyz"...
Admin
I first learned C as a co-op student in 1984, so I'm fairly accustomed to the semantics. But I can agree that they got this wrong-way-round. It would seem that the normal behavior would be to not fall-through, so that should have less decoration than the less common case....so as to draw attention to the uncommon case by the presence of something rather than its absence.
Admin
C is best thought of as a high-level assembly language. The C switch statement is an analog of the computed jump table. You jump in anywhere, and then execute unless or until you jump out. You'd be right, if someone was carefully designing a high-level programming language. But if what they were doing was writing a better assembler... you get jump tables.
Addendum 2021-08-24 23:13: Incidentally, I also first learned C as a coop student in 1984. I bet there weren't more than a few dozen of us. (a hundred?)
Admin
I disagree with the disagreement. The less restrictions a language has, the less a compiler of static checker can verify. Similarly, less restrictions also mean that less assumptions can be made when reading other peoples code (where "other people" includes "myself a few weeks ago").
Obviously, taking away too many tools isn't going to help either. But even then it matters what's the default behavior; For instance it makes sense to make fall-through in switch statements possible but not the default. Or to make immutability the default. Or to constrain the scope of variables to the smallest possible unit (usually a block) and require explicit declaration otherwise, when needed.
And commonly removing a dangerous feature necessitates adding more suitable tools for the purpose. Like having variables instead of directly writing stack instructions.
The equivalent for the surgeon was already given my someone else :/
Admin
One of the opportunities to feel young :) You learned C about two years before I was even born. To think that it already feels weird reading about programming blunders from the early 2000s, where my only programming experience of any scale was scripting for Ultima Online server emulators.
Admin
We aren't really in disagreement here. I completely agree that we need sane and sensible defaults. Which for all practical purpses means defaults that as much as is practical match the most likely use case. It's just that, as you as well say, we dislike the idea of making those use cases the only ones you can use.
And the later is what a lot of modern languages (cough java cough) have done. They take the most common use cases and declare them to be the "safe" things you can do. And than they cut out everything else. This is not so much the case with modern java and C# any more. They got good. But if you remember early Java and how bad it was... ugh.
And to me, that is a fundamental violation of what a programming language as a tool is supposed to do. That being to give you the ability to do your job efficiently.
Honestly of all the "modern" languages I have used in my many decades C++ is probably my favorite. Especially modern C++. You have all the fancy modern bells and whistles like classes and smart pointers to hold your hand and make difficult things easy and complicated work safe. But it also does not pointlessly restrict you. If you know exactly what you are doing and how to do it the language gives you the freedom to actually do it. Even if that means literally typing ASM code.
You don't have to do it. Indeed, you should not do it most of the time. And that is as it should be. But equally if you need to do it you can do it. Which also is as it should be.
Admin
In Swift, “case” is followed by a comma-separated list of values, like case 1, 2, 3: xxx;