|
CodeBabes and CodeDicks
|
#
?
Apr 26, 2014 22:16
|
|
|
|
| # ? May 17, 2024 14:10 |
|
|
The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Coding whores: post the coders that makes you laugh (or cry)
|
|
#
?
Apr 26, 2014 22:30
|
|
|
CodeDicks is a parody, of course.
|
|
#
?
Apr 26, 2014 22:35
|
|
|
I'm always impressed at the rate parodies like this can be produced. Maybe they just had all those photos laying around?
|
|
#
?
Apr 26, 2014 22:42
|
|
|
Verloc posted:Inherited yet another codebase of dubious quality. Why are users bitching about poo poo being broken constantly, data being corrupted, and not a goddamn thing showing up in the logfiles or system event log? What the shi... Yeah, at one point the project that I mentioned in this post was full of those. I once glanced at an old version of the code and nearly every function had its body surrounded with try { ... } catch (Exception) { }.
|
|
#
?
Apr 26, 2014 23:29
|
|
|
rjmccall posted:Go's design is admirably simple, but it does force some style decisions that I'm not thrilled about, like always putting binary operators on the end of the line instead of the beginning of the next. Any thoughts on Rust?
|
|
#
?
Apr 28, 2014 04:37
|
|
|
Color Gray posted:Yeah, at one point the project that I mentioned in this post was full of those. I once glanced at an old version of the code and nearly every function had its body surrounded with try { ... } catch (Exception) { }.   Silent Catch Safari™ continues this week with more searching on variations of catch(Exception). So far I have found several examples of this noble beast majestically roaming the App_Code directory: try{...} catch(Exception){throw;} Yup, caught the exception! 
|
|
#
?
Apr 28, 2014 14:52
|
|
|
Verloc posted:'sup "Opened the solution and immediately regretted my decision" buddy. This seems like an ideal use case for Roslyn.
|
|
#
?
Apr 28, 2014 14:54
|
|
|
Ithaqua posted:This seems like an ideal use case for Roslyn.
|
|
#
?
Apr 28, 2014 16:18
|
|
|
Verloc posted:I've never played with Roslyn, or really any code analysis tools beyond dotCover and what's built into ReSharper. Could you lay some knowledge on me as to Roslyn and why it might make Daddy drink less when dealing with this code base? I'm just thinking that you can use Roslyn to parse all of the code files and then investigate the parse tree to find empty catch blocks or catch blocks that just rethrow. If I have time I'll install the latest CTP and see if I can hack something together.
|
|
#
?
Apr 28, 2014 16:55
|
|
|
C code:Yes, there is no free(jb2). Yes, indents are 3 spaces. There are tons of functions that use this code. Copying and pasting this code twice results in a variable redefinition, so every logical block of code that needs to print more than once is separated into multiple functions, each ending with this code. As I've previously posted, each variable starts with "j" to include Jesus.
|
|
#
?
Apr 28, 2014 17:09
|
|
|
contrapants posted:Yes, indents are 3 spaces. That's good. 3 is a pleasing number of spaces.
|
|
#
?
Apr 28, 2014 17:51
|
|
|
contrapants posted:
Calling malloc at all is probably a bad decision in that context 
|
|
#
?
Apr 28, 2014 18:09
|
|
|
contrapants posted:Yes, indents are 3 spaces.
|
|
#
?
Apr 28, 2014 18:35
|
|
|
Otto Skorzeny posted:Calling malloc at all is probably a bad decision in that context It really is. Soricidus posted:Do the 3 spaces represent the Trinity, by any chance? Has the author considered the possibility that 7 might be a holier number? Oh, geez. It probably does. I never thought of that. The original author was one of the only people I've ever heard of in this company to get laid off. I'm going to find someone who worked with him and ask.
|
|
#
?
Apr 28, 2014 18:43
|
|
|
I bet he said a little prayer to himself before opening a codebase or starting edits on a file, like how you see people do that in restaurants before eating.
|
|
#
?
Apr 28, 2014 18:52
|
|
|
substitute posted:I bet he said a little prayer to himself before opening a codebase or starting edits on a file, like how you see people do that in restaurants before eating. Looking at the resulting code, God did not answer his prayers.
|
|
#
?
Apr 28, 2014 19:12
|
|
|
Holyghost
|
|
#
?
Apr 28, 2014 19:14
|
|
|
contrapants posted:Looking at the resulting code, God did not answer his prayers.
|
|
#
?
Apr 28, 2014 19:22
|
|
|
Otto Skorzeny posted:Calling malloc at all is probably a bad decision in that context I was going to mention this too but I wasn't too confident in my knowledge of C.
|
|
#
?
Apr 28, 2014 19:30
|
|
|
We're trying to hire PHP devs. We demand code samples. One of the applicants sent in the weirdest drat pseudo-OO code. Bad formatting, weird keyword capitalization, outdated practices, lack of any PHP idioms, horrible mixing of logic and HTML... finally boiled it down to a single representative comment. * Description: This is a simple validation function for any {part} strait conversion from cls{Part}.vb Yup, he submitted PHP code that he translated into PHP directly from Visual Basic. If you're going to send a code sample out to someone that wants to hire you, shouldn't you be proud of the code you're sending? I know that trying to hire people that both want to write PHP and have any sort of talent can sometimes be a challenge, but this is ridiculous.
|
|
#
?
Apr 28, 2014 19:36
|
|
|
ran into the following predicate in some old legacy code defining a view. where M.mf_id in (10,20,30,40,50) and ((type_PL = 'D' and mf_id = 30) OR mf_id != 30) and ((type_PL = 'P' and mf_id = 40) OR mf_id != 40) and ((TYPE_PL = 'R' and mf_id = 50) OR mf_id != 50) The unnecessary convoluted syntax was in and of itself screwing up the optimizer... also I have a personal hatred of inconsistent alias usage and capitalization.
|
|
#
?
Apr 28, 2014 19:50
|
|
|
You have a value sitting in a decimal? property of another object that lives in an unreliable session cache. This value needs to be currency formatted and populated into a textbox on a web form. Do you: A. Check if the decimal? has a value and if so, format it's Value and populate the textbox. B. Null-check the decimal?'s parent object to avoid a potential NullReferenceException and then do the steps outlined in A C. Blindly attempt to parse the decimal? to a currency styled double and then .ToString("C") the resulting double and use that to populate the textbox, ignoring any exceptions. My predecessor of course picked C. Truly this codebase is the gift that keeps on giving. 
|
|
#
?
Apr 28, 2014 19:56
|
|
|
McGlockenshire posted:We're trying to hire PHP devs. We demand code samples. God help you, because no one else can 
|
|
#
?
Apr 28, 2014 21:39
|
|
|
Verloc posted:You have a value sitting in a decimal? property of another object that lives in an unreliable session cache. This value needs to be currency formatted and populated into a textbox on a web form. Hey, look on the bright side: You learned some new stuff about Roslyn today. Might I also recommend running FxCop/Code Analysis on the application? It'll return a billion problems of varying severity (like naming convention violations), but you can configure it to suppress the less important stuff.
|
|
#
?
Apr 28, 2014 22:07
|
|
|
Toady posted:Any thoughts on Rust? I'll just say that the Rust semicolon thing is the purest example of over-cleverness in PL design that I think I've ever seen. It takes a long, long series of questionable decisions to end up somewhere so clearly laughable and yet not feel like there's anything you can do about it. ETA: The way I wrote this implied things I didn't mean. Rust has been, essentially, an open-source industrial research project in PL. By industrial, I mean that its end goal is to create a useful product with fairly specific requirements (to wit: it has to be possible to write a competitive web browser in it), not to serve as an open-ended academic research platform. That's led them in some really interesting directions, and I think that's been great. It does, however, look like they've recently decided that most of those research directions aren't worth pursuing, and so they're converging on a language that's not all that compelling to me, and that has a frankly quirky jumble of ideas about syntax. rjmccall fucked around with this message at 23:10 on Apr 28, 2014 |
|
#
?
Apr 28, 2014 22:26
|
|
|
What's the Rust semicolon thing?
|
|
#
?
Apr 28, 2014 23:54
|
|
|
Dicky B posted:What's the Rust semicolon thing? In Rust, however, this is not a purely stylistic decision: the presence or absence of a final semicolon changes the semantics of the block.
|
|
#
?
Apr 29, 2014 00:46
|
|
|
Rust's semicolon is basically just C's comma operator with an implicit () at the end if you don't put an expression after the last one. It'd be pretty horrifying in a dynamically typed language but I don't really see what's wrong with it in a language where the compiler will tell you if you forgot a trailing semicolon or added an extra one.
|
|
#
?
Apr 29, 2014 01:03
|
|
|
The Rust Semicolon Thing: If you have a match thing, likecode:code:There's plenty of places where people use that to write, like, fn f() { if blah() { whatever() } else { another_thing() } } where they could just have written return both times and added a semicolon, just for conciseness, but it's really more useful in the general "I'm not about to return from the whole function but I'm using this block/match/if-else as an expression" case. If you wanna talk about Rust syntax horrors I'd rather talk about how the everything-is-an-expression thing lets you write stuff like loop { f(return 42 + break); } and it will compile and not call f.
|
|
#
?
Apr 29, 2014 02:30
|
|
|
Plorkyeran posted:Rust's semicolon is basically just C's comma operator with an implicit () at the end if you don't put an expression after the last one. It'd be pretty horrifying in a dynamically typed language but I don't really see what's wrong with it in a language where the compiler will tell you if you forgot a trailing semicolon or added an extra one. Well, for one, I actually think expression-languages are a terrible idea in practice. Programmers hate naming things, and they love to feel clever, and expression-languages turn "not naming things" into a kinda fun little puzzle, so you naturally end up with these horrific deeply-nested twenty-line expressions with massive blocks of code center-embedded into a dozen different operations, instead of being broken up cleanly into a sequence of discrete statements. And this seems to be pervasive across every expression-language, with the partial exception of Haskell only because do-notation is basically statement-based. And the few things that are well-served by an expression language — like not needing a special ternary operator, or being able to encapsulate some helper variables needed during the initialization of some object — are easy to do with special cases or other language features. So a subtle language rule that only exists to serve the conceit of an expression-language is not off to a good start with me. But then Rust's rule is (IIRC) independent of whether the context actually uses the "result" of the block, which means that the type checker will sometimes just randomly complain about a type mismatch if the last line in a block doesn't have a semicolon but happens to produce a value other than (). And that puts you in the mindset of always using semicolons to get consistent behavior, which means you have to remember to remove them when you're feeling like solving a clever expression-language puzzle today. It all adds up to both writers and readers having to think way too much about semicolons.
|
|
#
?
Apr 29, 2014 03:29
|
|
|
I've designed braces 'n semicolons expression-languages independently of Rust and came up with the same missing semicolon logic. It has nothing to do with being "clever", it's a decision made purely out of necessity. It's better than having explicit return statements scoped to their own lambdas -- and when your for loops are actually lambdas (or was that just do blocks?) you run into trouble. It's better than having other types decay to void. It's better than making everybody put () after their last semicolon. I suppose you could replace it with some worse syntax, but that would be worse. It's not a subtle language rule, either. Complaining about this is like complaining that you have to explicitly return from functions in C instead of having it just use the last expression, because you forgot to include a return keyword. You're making a complaint about a language being different and unexpected solely because some superficiality is not what you're used to.
|
|
#
?
Apr 29, 2014 04:42
|
|
|
Yes, PHP is loosely typed, so...php:<? (not a function, or class) //DEFAULTS $url = ''; $prev_link = ''; $next_link = ''; $derp_array = array(); $url_array = array(); $pagination_array = array(); $page_title = 'Derp!'; $page_description = ''; (END not a function, or class) ?>
|
|
#
?
Apr 29, 2014 05:16
|
|
|
shrughes posted:I've designed braces 'n semicolons expression-languages independently of Rust and came up with the same missing semicolon logic. It has nothing to do with being "clever", it's a decision made purely out of necessity. I did describe it as the end point of a long series of questionable decisions. I will happily concede that the chief mistake is making an expression-language. Making an imperative expression language with braces and semicolons is just a refinement of that mistake. shrughes posted:It's better than having explicit return statements scoped to their own lambdas -- and when your for loops are actually lambdas (or was that just do blocks?) you run into trouble. It's better than having other types decay to void. It's better than making everybody put () after their last semicolon. I suppose you could replace it with some worse syntax, but that would be worse. There's nothing wrong with a decay to void rule if you only allow it for block results.
|
|
#
?
Apr 29, 2014 05:43
|
|
|
rjmccall posted:There's nothing wrong with a decay to void rule if you only allow it for block results. Yes there is. It's more complicated. Type inference with if-then-else expressions (or multiple expressions going to a generic type) becomes skeezier and either requires more explicitness or pushes type errors away from the code at fault. Instead you could just have { x; } return void and { x } return the type of x. That's less complicated and better. The last thing the type checker needs is "is this a block" logic on every node.
|
|
#
?
Apr 29, 2014 06:06
|
|
|
Verloc posted:'sup "Opened the solution and immediately regretted my decision" buddy. Here's one of the best examples from mine: code:
|
|
#
?
Apr 29, 2014 06:09
|
|
|
shrughes posted:Yes there is. It's more complicated. Type inference with if-then-else expressions (or multiple expressions going to a generic type) becomes skeezier and either requires more explicitness or pushes type errors away from the code at fault. Instead you could just have { x; } return void and { x } return the type of x. That's less complicated and better. The last thing the type checker needs is "is this a block" logic on every node. Sorry, I meant "block results that are clearly unused". The only case where that's not trivial to decide at parse-time is a function body result. In the absence of an explicit void type annotation, emitting a type-mismatch error there seems preferable to making semicolons significant. Sorry that you like to turn trivial implementation hurdles into annoyances for your users, though.
|
|
#
?
Apr 29, 2014 06:41
|
|
|
Found this in one of my old TSQL procedures. My god, I'm an idiot. (Names changed to protect the not-so-stupid) code:code:
|
|
#
?
Apr 29, 2014 07:08
|
|
|
rjmccall posted:I did describe it as the end point of a long series of questionable decisions. I will happily concede that the chief mistake is making an expression-language. Making an imperative expression language with braces and semicolons is just a refinement of that mistake. I haven't heard the term "expression language" used in this sense before. Are you referring to languages that have only expression and no statements? Or languages where every code unit has to return a value? "Imperative expression language" is an oxymoron to my uniformed self.
|
|
#
?
Apr 29, 2014 07:50
|
|
|
|
| # ? May 17, 2024 14:10 |
|
|
LOOK I AM A TURTLE posted:I haven't heard the term "expression language" used in this sense before. Are you referring to languages that have only expression and no statements? Or languages where every code unit has to return a value? "Imperative expression language" is an oxymoron to my uniformed self. Yes, I mean languages that generally lack distinct statements. If there are any primitive control-flow structures, they're just kinds of expressions. Most languages do still distinguish declarations, at least at the top level, but if there's a statement-like production which includes declaration and expressions, that's all it contains. There's no particular reason a language like this has to have any other traits associated with functional languages. If any of those primitive control-flow structures are jumps, of course, the language pretty much has to (1) be strict and (2) define a precise order of evaluation; but if the language allows expression evaluation to cause or rely upon side-effects — and almost all functional languages do, by necessity, even if that's not the favored style — then it's probably strict with a precisely-defined order of evaluation anyway. To be pleasant to do imperative programming in, a language really needs something like Rust's block expressions or Haskell's do notation, which allow a sequence of arbitrary interleaved declarations and expressions without too much syntactic overhead. Otherwise you'll be stuck with something like SML, where you're writing awkward crap like let n = event.repeat_count in (total := !total + n; let v = seed() in runNTimes n f v). rjmccall fucked around with this message at 08:40 on Apr 29, 2014 |
|
#
?
Apr 29, 2014 08:37
|
|