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

Vinterstum · # ¿ Apr 19, 2009 22:46

Mick posted:

Maybe it's just me. In any case, the intellisense over the events on that component looks like this now:

DataBinding
DataBound
Disposed
evtMyFooEvent
Init
Load
PageIndexChanged
PageIndexChanging
[etc.]

Breaking with the existing code standard of the class is bad form, sure, but a coding horror?

Adbot · # ¿ Apr 19, 2024 05:23

Vinterstum · # ¿ Apr 27, 2009 21:18

Janin posted:

What's the problem here?

Lambda calculus is a horror in itself.

Vinterstum · # ¿ Jun 30, 2009 13:55

Zakalwe posted:

From the Bullet SDK User Manual

So why is this a coding horror, exactly?

There's been plenty of console SDKs with very dodgy STL implementations which could've prompted that, and not necessarily the good ol' "not invented here" syndrome.

Vinterstum · # ¿ Jun 30, 2009 20:10

Zombywuf posted:

If you do not think of that as a coding horror, you do not belong here.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

And if you do, you most definitely don't belong in the gaming industry.

Vinterstum · # ¿ Jun 30, 2009 20:22

TheSleeper posted:

How many items in that "Motivation for EASTL" have to do with portability/compatibility? One. How many have to do with performance and/or common issues that come up in game programming but not elsewhere? (hint: it's all but the one).

The Bullet library is primarily used in the games domain, so what does it matter what's true elsewhere?

I'm not saying the STL is bad, but there's certainly some valid arguments against using it in console development. Which is why calling the decision a "coding horror" is just absurd.

Vinterstum · # ¿ Jun 30, 2009 22:13

Zombywuf posted:

Nothing wrong with writing their own STL implementation for consoles, apart from STL implementations being a dime a dozen. Or with writing their own STL for performance reasons (the EASTL doc reeks of crazy though). Instead they decided to use their own array object for compatibility reasons?

Really the EASTL doc reads like it was written by a genius, about 20 years after his peek, just as he's starting to be destroyed by drink.

Looks like it was for Visual Studio compatibility: http://bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=3638&p=13749&hilit=std%3A%3Avector#p13749

Oh the HORROR!

Vinterstum · # ¿ Jul 1, 2009 07:18

Zakalwe posted:

I have a really hard time believing that VS2008 has a broken implementation of something as pervasive in C++ code as std::vector.

Instead I'm inclined to believe they're doing something dumb and out of spec that works in GCC and therefore "VS2008 is broken".

Something dumb like wanting some of their internal data types to be 16 byte aligned, which the VS STL implementation can't handle (We actually had problems with this at work as well, I remember).

Again: Oh, the horror!

Vinterstum fucked around with this message at 07:20 on Jul 1, 2009

Vinterstum · # ¿ Jul 2, 2009 10:40

Avenging Dentist posted:

Hate to break it to you, but Visual Studio's STL implementation is by Dinkumware and is generally regarded as being pretty good.

(Also if your problem with an implementation of the STL is that it doesn't let you violate the standard then you are probably an idiot.)

Strawman much?

1. The Bullet guys needed some of their data to be 16 byte aligned.
2. The VS/Dinkumware std::vector implementation can't handle that.
3. Hence they now use their own array class to be able to remain compatible with VS.

I still fail to see the problem with any of this.

Oh, and the root of the problem is a single function (resize()) in their implementation which passes its second parameter by value instead of by reference, which Microsoft or whomever hasn't bothered to fix for an eternity, and is why quite a lot of people 1) patch the Dinkumware STL themselves, or 2) use a different implementation. But hey, maybe we just shouldn't use those pesky SSE instructions and just stick to the basics.

Vinterstum · # ¿ Jul 2, 2009 12:49

digibawb posted:

Doesn't the standard say it's pass by value?

Actually, yeah it does, though it seems to be a somewhat heavily debated issue (and seems likely to change).

Then I'm unsure why this causes a problem with using SSE intrinsicts only for this implementation and not the others. Edit: Actually, STLPort makes it a const ref.

Anyway, this is a bit of a derail. Back to the real horrors!

Vinterstum fucked around with this message at 12:54 on Jul 2, 2009

Vinterstum · # ¿ Aug 21, 2009 22:09

wolf_man posted:

a goddamn do while in PHP5!.

Not having touched PHP in many years (thankfully), I guess I'm missing something here. What's the coding horror, that he should be using foreach() instead or something? What specifically makes do-while loops poo poo in PHP5?

Vinterstum · # ¿ Aug 22, 2009 09:57

oldkike posted:

Saw this today:

code:

SpecialObject *o;
try 
{
  o = dynamic_cast<SpecialObject*>(globalPointer->getObj(SPECIAL_OBJECT); // getObj does not throw
} catch (...)
{
 o = NULL;
}

dynamic_cast is the real horror here.

Vinterstum · # ¿ Aug 28, 2009 07:15

Plorkyeran posted:

Lines 6921-6934 of a 10458 line function:

Oh WoW addons, you'll be the doom of us all.

EDIT: Hah, not an addon, a "direct simulation therycrafting tool" :eng101:

Vinterstum fucked around with this message at 07:17 on Aug 28, 2009

Vinterstum · # ¿ Sep 3, 2009 18:10

royallthefourth posted:

Seems like it should go the other way around, right? Technical competence should come before being able to make small talk with a moron.

Not at all. Technical competence is completely useless in a company if you're unable to function properly in a team (which includes "small talk" with "morons").

Vinterstum · # ¿ Sep 3, 2009 19:22

Avenging Dentist posted:

Haha no.

Well said sir, well said.

Vinterstum · # ¿ Sep 3, 2009 19:35

Lexical Unit posted:

I'd have to agree with AD. I work with some people who couldn't have a normal conversation with someone outside their field of work (or much of the time inside their field of work), especially if they tried. But they get their job done just fine.

I'm not talking about the typical social awkwardness kind of thing that a lot of us have, I'm talking about the arrogant cowboy-coder style of attitude (which is what I got from the OP), where anyone who isn't a good coder in their eyes is a "moron" and not worth their time, and typically indicates someone who'll do whatever they drat well please whether it's what they're supposed to do or not.

Vinterstum · # ¿ Sep 3, 2009 20:16

Zombywuf posted:

Yeah, in the context of interviews where technical issues are ignored that's exactly what the op sounded like.

He said he already went through a round of technical issues with a developer, before talking to the "suit". So yes, he did.

Vinterstum · # ¿ Sep 3, 2009 20:28

Zombywuf posted:

Phone interviews are for screening. I'm interested in knowing what use an interview with a single non technical person would be.

Second level of screening, maybe, HR making sure they don't waste the time of the actual devs on an interview with someone who'd never fit in. Not saying it's something I would've done personally or that it's what happened here, but I've heard about similar things before (you meet first with HR, after a chat they'll either bring in a lead dev or they'll tell you they'll "contact you later").

Vinterstum · # ¿ Dec 19, 2009 19:08

Goreld posted:

Am I the only person that stores the (PI/180) or (180/PI) part beforehand as a macro, define, variable, or whatever? I know that a nonretarded compiler should convert it into a multiplication operation, but I'm so used to avoiding unnecessary division at all costs that it's just a habit.

A nonretarded compiler would store that as a constant, actually. So yeah. Don't

. At least not for that reason.

Vinterstum · # ¿ Jan 6, 2010 22:26

AzraelNewtype posted:

how does that even happen?

Typically in cases like these: The case statements probably did something else at some point, and the whole thing hasn't been properly refactored as it's been changed. Pretty common; any codebase that's been around for a few years will have plenty of dead code and things like this. Only thing you can really do to minimize them is to encourage people to fix 'em up when they see them.

Or the original author was just on crack, who knows.

Vinterstum fucked around with this message at 22:28 on Jan 6, 2010

Vinterstum · # ¿ Mar 18, 2010 02:39

....and the thread reaches another low point.

To get bach on track, I present you with an excerpt from the Blob class. It hasn't seen use in a long, long time (or very possibly ever), but still lurks around in our Perforce history somewhere and is occasionally brought out to scare fresh coders.

code:

Blob_c::Blob_c(uint nSize)
{
    m_pData = reinterpret_cast<uint*>( new uchar[2*sizeof(uint) + nSize] );
    m_pData[0] = HostToLittleEndian_v( e_Norm + 1 );
    m_pData[1] = HostToLittleEndian_v( nSize );
}
Blob_c::Blob_c()
{
    m_pData = m_aNull;
    atomic_inc((int*)m_pData);
}
Blob_c::Blob_c(const void*p, uint nSize)
{
    new (this) Blob_c(nSize);
    memcpy( &m_pData[2], p, nSize );
}

Edit: For completeness, m_aNull is defined as:

code:

uint Blob_c::m_aNull[] = { e_Null+1, 0 };

Vinterstum fucked around with this message at 02:58 on Mar 18, 2010

Vinterstum · # ¿ Apr 20, 2010 21:03

Ugg boots posted:

http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf posted:

gcc has removed tail recursion for years. icc, suncc and msvc don�t.

That paper talks about C, though. I'd imagine the situation would be pretty different in C++ when you have objects on the stack that needs destruction.

Vinterstum · # ¿ Jun 14, 2010 22:29

Plorkyeran posted:

Having both assignment by value and assignment by reference in a language really isn't much of a horror.

I'd say having to change such a fundamental feature of a language from one revision to another definitely counts as a programming language horror.

Vinterstum · # ¿ Jul 6, 2010 23:42

In another blog post he talks about how he made a program that measures keystrokes per minute, and made all the coders on his team install it. So he can... monitor their productivity.

Oh God.

quote:

Yes! It works wonders. With attention drift practically eliminated, our code base has doubled in just the few months we've been running with this setup!

Measuring progress by the lines of code produced is an AWESOME idea, surely! :psyduck:

Vinterstum · # ¿ Mar 12, 2011 16:05

ymgve posted:

What the gently caress are they doing where looking up stuff by process ID is so time critical it accounts for a 50% speed increase?

50% speed increase of that operation, even. Whatever they're doing, they probably shouldn't be doing it.

I like how the guy is defending his decision by talking about his 40 years in the industry and all the stuff he's done...

Adbot · # ¿ Apr 19, 2024 05:23

Vinterstum · # ¿ Aug 30, 2011 23:42

Ugg boots posted:

Shut your mouth Perforce is awesome.

Perforce is awesome, Git is awesome, Perforce + Git should thus be super awesome!