[OT] Was: totally satisfied :D

[H. S. Teoh]

On Fri, Sep 21, 2012 at 05:38:06PM -0400, Nick Sabalausky wrote:
> On Fri, 21 Sep 2012 22:13:22 +0200
> "Paulo Pinto" <pjmlp at progtools.org> wrote:
> 
> > On Friday, 21 September 2012 at 19:09:48 UTC, H. S. Teoh wrote:
> > >
> > > The saddest thing is that people are paying big bucks for this
> > > kind of "enterprise" code. It's one of those things that make me
> > > never want to pay for *any* kind of software... why waste the
> > > money when you can download the OSS version for free? Yeah a lot
> > > of OSS code is crap, but it's not like it's any worse than the
> > > crap you pay for.
> > >
> > 
> > Welcome to my world. As a Fortune 500 outsourcing consulting company
> > employee, I see this type of code everyday.
> > 
> 
> I find it depressing to see just how *easy* it is to have
> dailywtf-worthy material. They anonymized my name as Nate here:
> 
> http://thedailywtf.com/Articles/We_Have_Met_the_Enemy.aspx

LOL... I should submit the ipv6 prefix checking code that does
conversion to string.

The sad part is that so many of the commenters have no idea that
adjacent C literals are concatenated at compile-time. It's a very nice
way to put long strings in code and have it nicely indented, something
that is sorely lacking in most languages. But regardless, why are they
posting if they clearly don't know C that well?!


> Note also that the "' ...code here" and "' ...more code here" sections
> were typically HUGE.

Speaking of 1000-line functions... yeah I routinely work with those
monsters. They tend to also have a ridiculously long list of parameters,
which over the history of the function have been added one by one as
people felt the need for Yet Another Variation on the function's
capabilities.  Most of those parameters are either meaningless or
ignored most of the time (necessitating ridiculously long lists of
null/dummy values every single time the function is called), save for
one or two exceptional cases when most of the *other* parameters aren't
needed. Calling the function with unforeseen combinations of parameters
usually triggers a bug caused by unexpected interactions between
parameters that were assumed to be independent.


> And that was only scratching the surface of the lunacy that was going
> on there - both in and out of the codebase.

I have seen code whose function names are along the lines of "do_it()"
and "do_everything()". As well as "do_main()" and
"${program_name}_main()" in addition to "main()".


> I've been sticking to contract stuff now, largely because I really
> just can't take that sort of insanity anymore (not that I ever could).
> If I ever needed to go back to 9-5 code, or cubicles, or
> open-floorplan warrooms, I'd *really* be in trouble.

I really should start doing contract work. Being stuck with the same
project and dealing with the same stupid code that never gets fixed is
just very taxing on the nerves.


T

-- 
Blunt statements really don't have a point.