Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›2 »

zootm: Aug 8, 2006; We used to be better friends.

nebby posted:

For the record, say what you will about "bln_flg_tst_cnd_args_x", but I still think calling a return value "ret" or "result" is the goddamn stupidest idea I saw posted in all of those trainwrecks of threads I started.

If you're using a variable to build the result of a function, result seems a pretty natural name for the variable. Because it contains the result.

nebby posted:

Cl<S,T> indicates a Java closure (which is just a anonymous class meeting one of the interfaces below) mapping from type S to T.. Clp<T> is a predicate closure (T => boolean), Clv<T> is (T => void) and Clvv is double void closure (void => void).

There's a bunch of frameworks for Java which do stuff a bit like this (and these aren't really closures, the term used in Java is "anonymous inner class" for this sort of thing, and "functor" for the pattern you're following). They're a reasonable-if-verbose analogue to closures.

"Predicate<T>" seems a better name than "Clp<T>" (it is, after all, the name being used for its addition to Java in the next version), for what it's worth. Also, Clvv is java.lang.Runnable except less self-documenting. Also also if Runnable is useful to you, java.util.concurrent.Callable<T> probably will be too, which is a combination you missed.

nebby posted:

Bring on the hate, but I'd love to see your examples of functional constructs in java that don't read like a goddamn essay.

Considering you've basically replicated the existing stuff for this sort of thing and made the variables slightly shorter at the cost of readability, it seems unlikely the examples would read significantly differently. Java is a verbose language in general and encoding the variable names isn't going to help any more with readability than removing all the vowels would.

On the other hand that kind of construct is definitely handy, which is why it's been implemented so many times in the past, and presumably why people seem to be finally integrating it into Java's libraries themselves. I'm not sure how I feel about closures in Java in general, though – Josh Bloch makes a good case showing the complexity they add to the language while removing readability, since there's been little actual consultation on the current BGGL Closures proposal. The proposal may well go through, though.

I don't know BGGL closures but with Scala (another JVM language), your last code example would look like this:

code:

val timeblocksUnderLearningNode = F.select(timeblocks, _.getParentNode.getParentNode == learningNode );

zootm fucked around with this message at 15:53 on Mar 29, 2008

# ¿ Mar 29, 2008 15:33

Adbot: ADBOT LOVES YOU

# ¿ Apr 23, 2024 11:03

zootm: Aug 8, 2006; We used to be better friends.

nebby posted:

For example, if you are writing a method called countOfApplesInBasket() that returns a count of apples, if I see the line "result += 1;" I have to look at context to determine wtf result is. In this case, it's a count of apples. It's much nicer to just call it something like "countApples", it doesn't require context and gives the variable a much more meaningful name. The "but you can always look at context" defense is what I got a lot of in my old threads but it's entirely missing the point because the overall goal of naming itself is to minimize the amount of unnecessary cross referencing of context by the programmer.

Just "apples" would suffice - why bother saying it's a count when it could be nothing else? On the other hand, generally speaking, if "result" is confusing, your method is too complex and you should simplify it.

nebby posted:

The fact that it is the value being returned (and the fact that the concept of "return values" exists in my language) shouldn't impact the name of my variables in a method written against a certain domain like apple counting. I'd argue that the vast majority of the time there is a better name than "result" or "x" or "i".

"result" just works well when you want a succint way to describe that you're building up the result to a self-describing function. Of course result shouldn't be used if it's at all confusing or ambiguous, but in sensible code it shouldn't ever be.

nebby posted:

And yeah, I realize "Runnable" and "Predicate" (and in .NET "Action") exist but my main issue is that when you are talking about something as fundamental as closures (or 'functors' as you put it, but Java anonymous inner classes pseudo-capture final variables and this variables so I think they are closures) that every extra bit of verbiage hurts and learning a few acronyms basically gets the ugly syntax out of the way so you can avoid reading it altogether. You'll note I just throw all the anonymous inner class declaration crap on the end of the line even though that's not canonical Java formatting.

Canonical Java formatting is something of a myth, but I don't think the spread-out version is any less readable. In particular, though, I don't think that the encoded names convey any useful information or make the code any more readable. I doubt anyone would even notice the fact that it's marginally shorter unless on a particularly-limited screen width, which hardly seems a useful case to optimise for.

Also, in this case "closure" isn't even what the objects are. "Closure" (or "anonymous inner class") is the language feature that you use to generate them. The actual objects are functors, or function objects, or just functions, or whatever you want to call them.

nebby posted:

And yeah, I like Scala from what I've read so far, but time constraints are keeping me from trying to get my Android app running on Scala (which actually works, supposedly.) I'll do it eventually though

My workmate got a Scala app running on J2ME, although it requires a little bytecode fiddling (relies on things like Comparable).

nebby posted:

Edit: Here's the same code with 'common sense' applied. It's probably more intuitive to most of the readers of this forum, but it feels like a sack of molasses to me, it turns what should be a one-liner in any sane language into an abomination.

I wouldn't say that Java wasn't a "sane" language, this is just a particular area where it falls over. Considering the language family it's from it's hardly surprising that it falls over here.

# ¿ Mar 29, 2008 18:05

zootm: Aug 8, 2006; We used to be better friends.

tef posted:

If we're going into unicode territory how about something like ∀ x ∈ l : print x; perhaps?

Been using Fortress, have we?

# ¿ Mar 31, 2008 17:28

zootm: Aug 8, 2006; We used to be better friends.

chocojosh posted:

I sometimes put the return expression in parenthesis simply because I find it more readable. Is that really a coding horror?

Like (return 1 + 2); or return (1 + 2);? I think in C-like languages I'd regard the former as something of a coding horror simply because it's so unusual that I wouldn't even know if it worked. Really strange.

# ¿ Apr 3, 2008 20:22

zootm: Aug 8, 2006; We used to be better friends.

chocojosh posted:

The latter. Note that I don't think I've ever done return (retVal); but I will do things like return (x + 10); or return (x > 0)

There's no problem at all with that, it was the other thing that'd confuse me.

# ¿ Apr 3, 2008 22:02

zootm: Aug 8, 2006; We used to be better friends.

I think either some spacing or avoiding the ternary operation altogether would make the "after" code in that example a lot easier to read, JingleBells.

I realise that readability wasn't the "horror" in the original, though.

# ¿ Apr 10, 2008 14:20

zootm: Aug 8, 2006; We used to be better friends.

Caching the prime numbers is memory-intensive. For the best performance profile you should calculate them on-demand each time.

# ¿ Apr 24, 2008 20:06

zootm: Aug 8, 2006; We used to be better friends.

The great thing about the prime factorisation solution is that you can have counted flags. It's like the flag equivalent of turning your amp up to 11.

# ¿ Apr 25, 2008 13:42

zootm: Aug 8, 2006; We used to be better friends.

Setting someone as logged in just because they passed a filename in the query parameter seems to me to be the horror here.

# ¿ May 10, 2008 00:53

zootm: Aug 8, 2006; We used to be better friends.

TheSleeper posted:

Well they obviously are quite a bit worse off since taking the uninitialized data out as a source of entropy apparently led to weak keys.

The guy removed both the section using uninitialised memory for entropy and a section which looked as though it was but which was not, which was the root of the problem. Check out the patch that caused the problem, and the fix.

# ¿ May 14, 2008 21:03

zootm: Aug 8, 2006; We used to be better friends.

CT2049 posted:

The only thing I can think is that then you can glance and easly see if your checking for the true case or the false case, but even that is so simple the == shouldn't be necessary.

Also it could be completely replaced by prefixing the condition with "!". There's really no excuse for the "== true" thing, it's dreadful style.

# ¿ May 15, 2008 23:09

zootm: Aug 8, 2006; We used to be better friends.

TSDK posted:

No it wouldn't.

In Java it would. Of course, it's not possible, so the point is somewhat moot. For what it's worth Scala uses "==" for (null-safe) value equality and "eq" for reference equality.

# ¿ May 16, 2008 10:44

zootm: Aug 8, 2006; We used to be better friends.

Zakalwe posted:

break my_label is no different than goto my_label as far as breaking out of loops is concerned. It just removes the functionality of one "evil" and sticks it in another.

This is largely correct but the essential point here is that goto should be limited to the point where execution paths can be easily determined. Gotos within local scope for breaking out of loops and the like are theoretically fine, but jumping between functions, jumping to arbitrary points to emulate flow control, and so on is craziness. There's definitely valid uses within C from what I've seen, though.

# ¿ Jun 15, 2008 14:42

zootm: Aug 8, 2006; We used to be better friends.

Standish posted:

Because it's needlessly verbose and also because "some_variable" can evaluate to true while "some_variable == true" evaluates to false e.g.
code:
int i = 42;
if (i)
{
   ... // code gets run
}
if (i == true)
{
   ... // code does not get run
}

In some languages where this is possible, there are good, concrete reasons why you would want to do this.

TRex EaterofCars posted:

It's just the way languages like C handle their if statements. Java specifically decided to not allow it to work that way because of the specter of "ambiguity".

Considering that C doesn't (or didn't, until C99) have a "true" boolean type, the "== true" thing is kinda meaningless there.

zootm fucked around with this message at 22:07 on Jun 20, 2008

# ¿ Jun 20, 2008 22:04

zootm: Aug 8, 2006; We used to be better friends.

I remember catching this one time in production C# code at an old job:

code:

try
{
    // Code here...
}
catch( Exception )
{
    int i = 0;
}

The explanation for this craziness was "I needed to put a breakpoint there". Gah.

# ¿ Jul 8, 2008 19:34

zootm: Aug 8, 2006; We used to be better friends.

In most Java debuggers, and I suspect in VS by now, you can set the system to break on exception. In any case I imagine putting at least a throw; in there would be preferable for when you forget to remove the code, so the semantics don't change.

# ¿ Jul 8, 2008 22:01

zootm: Aug 8, 2006; We used to be better friends.

RoadCrewWorker posted:

Still, how would declaring a block variable that gets lost after the catch{} is done change the semantics of the program?

The exception isn't re-thrown; an exception that would otherwise propagate is silently ignored.

It really is best to avoid munging your program at all to make it "easier to debug"; this sort of thing can be too easy to leave in to a stage where it's more expensive to find and fix.

Volte posted:

Can't you just put the breakpoint on the closing brace?

In most languages you can't breakpoint on a line that isn't executed; braces are just syntax.

# ¿ Jul 8, 2008 22:55

zootm: Aug 8, 2006; We used to be better friends.

OneEightHundred posted:

I'm still trying to find this.

I've no idea, I'm afraid I don't use Windows so finding it is kinda impossible for me.

Edit: I lie, Google apparently knows about these things. See under Breaking on Exceptions on this page.

Volte posted:

Well it works in Eclipse with MinGW/GDB.

That is some crazy-rear end poo poo. Good stuff though, would be nice if that worked more often.

zootm fucked around with this message at 23:21 on Jul 8, 2008

# ¿ Jul 8, 2008 23:19

zootm: Aug 8, 2006; We used to be better friends.

JediGandalf posted:

Why put it on the brace when you can put it on the catch statement itself?

Click here for the full 915x888 image.

(untested on earlier versions of VS. This is VS2008)

I'm not certain this worked in the version of VS we were using at the time (2003) but really the problem was the existence of the catch statement at all; the code was only supposed to have a finally block.

# ¿ Jul 10, 2008 09:34

zootm: Aug 8, 2006; We used to be better friends.

Sebastian Flyte posted:

Exactly. Doing a transaction with a single SQL command deleting one single row is pretty pointless.

There is occasionally value in doing the "right thing" in order that correctness is preserved if you add one more line, though.

# ¿ Jul 11, 2008 11:57

zootm: Aug 8, 2006; We used to be better friends.

Ryouga Inverse posted:

I was quite aggravated about this. No exceptions, nothing. I wish I could find the code again.

There is no guarantee that string literals will be interned, so surely this is an expected behaviour?

# ¿ Aug 29, 2008 13:52

zootm: Aug 8, 2006; We used to be better friends.

Mustach posted:

== and != are overloaded to do value comparison for Strings in C#.

Ah, fair enough. For some reason I thought it was just switch that was magic.

# ¿ Aug 29, 2008 19:32

zootm: Aug 8, 2006; We used to be better friends.

I think a lot of languages do it that way, actually. Certainly Ruby does as well. Doesn't seem like something that scales well to multiple threads (insert Ruby gag here) but it certainly seems pretty consistent with the way the language works, especially given that Exceptions are the best way to break normal control flow in exceptional cases.

Edit: It might be possible to override the default interrupt handler in these languages actually.

Edit 2: Yeah, Signal appears to let you override the default behaviour in Ruby, there's likely to be something analogous for Python. This makes the default behaviour seem more sensible.

Edit 3: And it's signal in Python. This seems like the best compromise where ctrl-C has a nice default behaviour that you can override.

zootm fucked around with this message at 18:04 on Nov 5, 2008

# ¿ Nov 5, 2008 17:53

zootm: Aug 8, 2006; We used to be better friends.

Zombywuf posted:

I wouldn't let exceptions escape signal handlers.

Why not? Anything else would be terribly inconsistent.

Zombywuf posted:

I certainly wouldn't define keyboard interrupt as an exception.

Why not? It creates the correct behaviour in the default case in a transparent and understandable way. And if you have some special handler, you can override the default behaviour simply. Sounds like the best of both worlds.

# ¿ Nov 6, 2008 23:47

zootm: Aug 8, 2006; We used to be better friends.

Zombywuf posted:

It only provides expected behavior in the case where you're trying to catch KeyboardInterrupt. When you're expecting the semantics of exceptions to mean "something has gone wrong with the code in my try block", the behavior will break your program.

The user requested that the program be interrupted, and the program execution was interrupted. That's the correct behaviour in most cases, especially since if it's not handled it will quit the program with an error code like a good citizen. If you are expecting exceptions to mean 'my code went wrong in a recoverable way' rather than 'there was an exceptional circumstance' you've got the semantics wrong. Blanket catching exceptions is a terrible idea for many reasons, and the fact that you catch user interrupts is a very minor one of those.

zootm fucked around with this message at 01:23 on Nov 7, 2008

# ¿ Nov 7, 2008 01:21

zootm: Aug 8, 2006; We used to be better friends.

Factor Mystic posted:

code:

year = ORIGINYEAR; /* = 1980 */

while (days > 365)
{
    if (IsLeapYear(year))
    {
        if (days > 366)
        {
            days -= 366;
            year += 1;
        }
    }
    else
    {
        days -= 365;
        year += 1;
    }
}

Whoops

Is this from the Zune? :ohdear:

Edit: Holy poo poo, it is. That'll teach me to joke about such things.

zootm fucked around with this message at 14:26 on Jan 1, 2009

# ¿ Jan 1, 2009 13:57

zootm: Aug 8, 2006; We used to be better friends.

Good lord. Although relational databases are terrible for scaling, this does sound as though it's the worst possible way around that.

# ¿ Jan 5, 2009 14:45

zootm: Aug 8, 2006; We used to be better friends.

thesaddestpirate posted:

code:

package java.lang;

public interface Runnable {    
     public abstract void run();
}

This is not a good example of bad naming in Java, and there are lots of good examples.

# ¿ May 12, 2009 20:15

zootm: Aug 8, 2006; We used to be better friends.

tef posted:

this for new cobol title

# ¿ Jun 9, 2009 13:48

zootm: Aug 8, 2006; We used to be better friends.

Parantumaton posted:

Java's String#replaceAll(String, String) is regex based which means there's the overhead of generating internal Pattern object for the actual regex, creating a Matcher object from the said Pattern object and then calling Matcher#replaceAll(String) to get the output. If all you need is simple replacement ("change all 'a':s to 'b':s") which is going to get used a lot in your application then rolling out your own #replaceAll() will actually result in a lot faster throughput than the Java's native regex one. Same applies especially to Pattern#split(String) too.

In reality, all the text above means that I've actually done the same thing myself and I need to justify my micro-optimizations to not fall into despair.

This is all potentially well and good but just look at the code they're using - there's no way it's an optimisation.

# ¿ Sep 5, 2009 10:09

zootm: Aug 8, 2006; We used to be better friends.

Zombywuf posted:

If you think that:

Have never heard of multi-agent ontology oriented programming

This does not make sense.

Also Actor/Agent/Process model is basically just asynchronous object-orientation. Message-passing actors are a really nice way of building but sometimes people act as though they're some kind of magic cure-all when they're not really all that different to how large systems were already engineered. Erlang's "big win" is nicely codifying and implementing the frameworks you need to get this sort of thing off the ground.

Don't know where I'm going with this. In any case these arguments seem secondary to the stated goal of coding horrors.

Edit:

ColdPie posted:

Should've known the 65 new posts weren't 65 new funny posts but instead 65 new posts arguing about functional programming.

Most of the time I just hear a fine hiss.

# ¿ Nov 30, 2009 16:57

zootm: Aug 8, 2006; We used to be better friends.

Zombywuf posted:

And one post whinging about people arguing about functional programming.

Sometimes a thread needs a good meta-whinge so it can get back on track.

# ¿ Nov 30, 2009 17:00

zootm: Aug 8, 2006; We used to be better friends.

MononcQc posted:

This kind of stuff was used in every god drat library file we had because at some point in history the site would have some kind of common library directory with a bunch of other sites we had on a single server. Said websites would sometimes call files coming from each other to allow some weird interactions.

Is the resemblance to C headers deliberate or did they arrive at the same solution independently? That's pretty horrifying though.

Zombywuf posted:

The only places I've seen anything similar are server/daemon monitoring tools. Erlang is the only place I've seen it as part of the language, this is another area where Erlang seems to be trying to subsume the UNIX philosophy.

It's actually technically part of the OTP library rather than the language, and (like quite a lot of the stuff in OTP) is something that appears missing in a lot of other languages' implementations of the actor model (I've seen it in Akka but it doesn't appear that that many people understand how important this aspect is). Erlang's library really is its interesting aspect.

# ¿ Nov 30, 2009 18:49

zootm: Aug 8, 2006; We used to be better friends.

It's probably intended to get as far as the database at which point it'll fail because "WTF" isn't a valid data type. Still a horror, though.

I like the "MONEY" type as well although I suppose that'll be a real uninteresting decimal type.

# ¿ Dec 4, 2009 00:28

zootm: Aug 8, 2006; We used to be better friends.

yaoi prophet posted:

I seem to recall the MONEY type being specially designed to avoid that sort of stuff, but I'm not 100% certain

The MONEY type is, yes, but that doesn't stop the fact that the variable which is being put into the MONEY field has type TYPE_FLOAT.

# ¿ Dec 4, 2009 13:07

zootm: Aug 8, 2006; We used to be better friends.

megalodong posted:

A novel implementation of str_replace(" ", "", $str):

I knew a guy who did something near-identical to this (in Java) when I was at uni. I suggested the single-line version and he just kinda looked stunned, then said he'd "maybe think about doing it that way later". Oh, well.

# ¿ Dec 22, 2009 16:26

zootm: Aug 8, 2006; We used to be better friends.

Mustach posted:

"And in the end, the love you take is equal to the love you pass by value." — John Lennon

It is actually that quote, although without the funny; from the source:

code:

=begin html
<p><i>"And in the end, the love you take,<br>
is equal to the love you make" - "The End", John Lennon/Paul McCartney (1969)</i></p>

# ¿ Dec 30, 2009 14:02

zootm: Aug 8, 2006; We used to be better friends.

MrMoo posted:

Not enough! Say hello to NIO.2.

NIO2 is, depressingly, the filesystem API that's been missing for Java. Local filesystem access on Java is woeful in a lot of regards at present.

# ¿ Jan 31, 2010 13:11

zootm: Aug 8, 2006; We used to be better friends.

Edit: Replied to Zombywuf without realising.

# ¿ Feb 9, 2010 14:28

Adbot: ADBOT LOVES YOU

# ¿ Apr 23, 2024 11:03

zootm: Aug 8, 2006; We used to be better friends.

TRex EaterofCars posted:

Yup, that's the web application servlet context and request being passed in. To a job. That runs via Quartz.
Also, processFulfillmentItems is even larger than this and has around 15 exit points.
gently caress.

There are so many horrors here I don't know where to start. Passing the contexts in to the method is just the tip of the iceberg. Terrifying.

# ¿ Sep 23, 2010 12:48

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›2 »