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!

«‹›1503 »

Steve French: Sep 8, 2003

Also, Deus Rex makes a good point about flatten vs recursive flatten. Ruby does define a generic recursive flatten, which can be handy, but it can also result in some incredibly opaque code when you just see somestructure.flatten and you don't know exactly what the entire structure looks like off the top of your head. Explicitly pulling out values in a for comprehension might be a little more code, but can be a whole hell of a lot more readable (depending on the language, Python seems admittedly handicapped in this regard).

# ? Jun 19, 2014 16:28

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 16:17

NFX: Jun 2, 2008; Fun Shoe

Jabor posted:

code:
while(!isReady());
code:
/(<([^ >]+)( [^>]*)?>(?1)<\/\2>)/
I'm sure everyone has a few more of their own.

I've run into a lot of these lately:

code:

if(!(ptr==NULL))

# ? Jun 19, 2014 16:35

Shugojin: Sep 6, 2007; THE TAIL THAT BURNS TWICE AS BRIGHT...

Ersatz Haderach posted:

e: Shugojin, if you have any choice in the matter and you haven't already, you need to learn R. It's a different kind of shambling abortion, but at least it's a free one and it still works a hell of a lot better than SAS. Imagine a deranged statistician designing a programming language after reading "Structure and Interpretation of Computer Programs" while on a bad acid trip.

Oh I know R. I am comfortable with R. The problem is that despite being able to do basically anything in R that SAS can do, HR people in the positions I want are instructed to look for SAS so I need to know it to get my resume past them :suicide:

I plan to blow the $55 to get a SAS certification and then try to do everything in R wherever possible anyway :v:

# ? Jun 19, 2014 16:36

Edison was a dick: Apr 3, 2010; direct current only

Skuto posted:

Python has no generic flatten. And that sucks.

itertools.chain.from_iterable gets close.

# ? Jun 19, 2014 19:02

Pythagoras a trois: Feb 19, 2004; I have a lot of points to make and I will make them later.

nielsm posted:

Python code:

if any(feature.value > threshold for d in dimension for feature in d):
  return 'failed'
else:
  return 'passed'

Like that, I believe.

drat, that's some good python. No sacrasm, that's just a good use of any and generators.

# ? Jun 19, 2014 19:14

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

[x for x in y for y in z] makes a great deal more sense than Python's [x for y in z for x in y]. I will explain why. When you go from

code:

for x in y:
    x

to [x for x in y], you take the "for" loop header from the "front" of the loop body and push it on at the "back" of the loop body. When you go from

code:

for y in z:
    for x in y:
        x

code:

for y in z:
    [x for x in y]

you again of course take the inner "for" loop header from the "front" of the loop body (ignoring the outer loop for the moment), and push it on at the "back". One would therefore expect to iterate this procedure, with the next case being [x for x in y for y in z] (where we have again taken the thing "in front" and pushed it on at the "back"). But the way Python has it, you instead have to jam it in the middle for some reason. It's wrong and bad.

The "flow" of [x for x in y for y in z] is very natural. We can break it up into three stages: "x", "for x in y", "for y in z". At each stage we introduce one new unknown as the parent of the previous stage's unknown. Initially we do not know what x is. At the second stage we find out what x is: it is an element of y (but we do not know what y is). At the final stage we find out what y is: it is an element of z (which since it is the outermost, we presumably know what it is). Compare that to what Python has us do, where we learn about "x" at the start, then have an interlude where we hear about "y" and "z" and ask ourselves, what are "y" and "z"? Why do I care about them, what do they have to do with x? I was happy with x. Then and only then do we learn, at the end, what relation y and z bore to x. It's rear end backwards. Or, more accurately, it's a confusing jumble; at least backwards is still in a recognisable order.

If the above didn't make my point, here is a diagram I made quickly in Paint.

See how there is an order in which you read each loop. In the case of the "nested for loop" form, you start at the top and proceed downwards. In the case of the sensibly-written list comprehension, you start at the right and go left. In the case of the badly-written version that Python mandates, you jump around like a maniac! Holy poo poo, what's going on?! How can that make more sense to anyone?

Hammerite fucked around with this message at 20:10 on Jun 19, 2014

# ? Jun 19, 2014 20:06

seiken: Feb 7, 2005; hah ha ha

You don't need to go into such detail to explain why Python's way is loving stupid

In any sane system you write [x for x in y for y in z] = [((x) for x in y) for y in z]. There is a consistent ordering of scope.
in Python you write [x for y in z for x in y] = [(x) (for y in z (for x in y))]? I guess? I mean you can't even parenthesise it sensibly, it just doesn't begin to make sense

# ? Jun 19, 2014 20:32

raminasi: Jan 25, 2005; a last drink with no ice

This is my favorite piece of R documentation.

Description: Melt a data frame into form suitable for easy casting.
Value: molten data
Not ever actually discussed: What the gently caress "melting" data means.

At least there are some examples:

code:

head(melt(tips))
names(airquality) <- tolower(names(airquality))
melt(airquality, id=c("month", "day"))
names(ChickWeight) <- tolower(names(ChickWeight))
melt(ChickWeight, id=2:4)

# ? Jun 19, 2014 20:49

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

GrumpyDoctor posted:

This is my favorite piece of R documentation.

Description: Melt a data frame into form suitable for easy casting.
Value: molten data
Not ever actually discussed: What the gently caress "melting" data means.

That's funny. I always thought of typecasting as in "that guy is typecast as the villain" not in terms of pouring poo poo into a cast. I didn't know this was a thing.

# ? Jun 19, 2014 21:10

Polio Vax Scene: Apr 5, 2009

I always thought of typecasting as "I'm going to use my +2 programmer's staff to cast this IWankable into a WankPole"

# ? Jun 19, 2014 21:18

Westie: May 30, 2013; Baboon Simulator

Manslaughter posted:

I always thought of typecasting as "I'm going to use my +2 programmer's staff to cast this IWankable into a WankPole"

Inane response to avoid needless but totally worth it emptyquoting.

# ? Jun 19, 2014 21:39

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Manslaughter posted:

I always thought of typecasting as "I'm going to use my +2 programmer's staff to cast this IWankable into a WankPole"

Pretty sure that would throw a ClassCastErection

# ? Jun 19, 2014 21:49

Coffee Mugshot: Jun 26, 2010; by Lowtax

A better compiler would know that a WankPole is Wankable and implicitly cast it for you.

# ? Jun 19, 2014 22:11

return0: Apr 11, 2007

Manslaughter posted:

I always thought of typecasting as "I'm going to use my +2 programmer's staff to cast this IWankable into a WankPole"

I am going to attempt to engineer a context where typecasting is discussed at work so I can say this!

# ? Jun 19, 2014 22:35

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

return0 posted:

I am going to attempt to engineer a context where typecasting is discussed at work so I can say this!

Go write it on a whiteboard right before somebody uses that room for an interview

# ? Jun 19, 2014 22:43

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

seiken posted:

You don't need to go into such detail to explain why Python's way is loving stupid

In any sane system you write [x for x in y for y in z] = [((x) for x in y) for y in z]. There is a consistent ordering of scope.
in Python you write [x for y in z for x in y] = [(x) (for y in z (for x in y))]? I guess? I mean you can't even parenthesise it sensibly, it just doesn't begin to make sense

In any sane system, [x for x in y for y in z] insults you and formats your computer for making a completely unreadable one-liner.

# ? Jun 20, 2014 00:00

seiken: Feb 7, 2005; hah ha ha

Suspicious Dish posted:

In any sane system, [x for x in y for y in z] insults you and formats your computer for making a completely unreadable one-liner.

So it's cool to add pointlessly, unnecessarily broken things to languages because you can always excuse it with well nobody should do that anyway.

# ? Jun 20, 2014 00:09

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

seiken posted:

So it's cool to add pointlessly, unnecessarily broken things to languages because you can always excuse it with well nobody should do that anyway.

I'm saying Python should never have allowed [x for x in y for y in z] in the first place, because it's a dumb confusing feature.

# ? Jun 20, 2014 00:16

seiken: Feb 7, 2005; hah ha ha

I'm not sure which particular construct you're saying shouldn't be allowed (list comprehensions entirely, double-fors, or double-fors where one clause is dependent on the other), but there isn't a particularly great argument for disallowing any of those in isolation

# ? Jun 20, 2014 00:30

FrantzX: Jan 28, 2007

This entire conversation about nested iteration in Python is proof that LINQ is the best thing ever.

# ? Jun 20, 2014 00:43

Mogomra: Nov 5, 2005; simply having a wonderful time

I have to agree.

# ? Jun 20, 2014 00:44

Shugojin: Sep 6, 2007; THE TAIL THAT BURNS TWICE AS BRIGHT...

GrumpyDoctor posted:

This is my favorite piece of R documentation.

Description: Melt a data frame into form suitable for easy casting.
Value: molten data
Not ever actually discussed: What the gently caress "melting" data means.

At least there are some examples:
code:
head(melt(tips))
names(airquality) <- tolower(names(airquality))
melt(airquality, id=c("month", "day"))
names(ChickWeight) <- tolower(names(ChickWeight))
melt(ChickWeight, id=2:4)

Yeah that does tend to be the way with R documentation. A description that's completely recursive and doesn't tell you a drat thing and some examples of usage.

# ? Jun 20, 2014 00:49

205b: Mar 25, 2007

features = itertools.chain.from_iterable(dimensions)

:colbert:

edit: this was already posted and I'm dumb

205b fucked around with this message at 20:23 on Jun 22, 2014

# ? Jun 22, 2014 06:39

baby puzzle: Jun 3, 2011; I'll Sequence your Storm.

I keep finding variations on this everywhere:

code:

void Derp::PerFrameUpdate()
{
   State newState = GetCurrentNetworkSynchronizedState();

   // operate on state delta ...

   m_oldState = newState;
}

Which is fine because states never change multiple times in one frame. Especially states coming from a machine elsewhere on the network... networks are 100% predictable.

# ? Jun 26, 2014 03:41

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Somebody poast the vBulletin source

# ? Jun 26, 2014 03:46

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Rendering a state that is stale but is less than a frame old is generally not a problem, and it's usually better to focus on rendering frames as quickly as possible over ensuring that they're as up-to-date as possible (as you could easily end up never rendering a frame otherwise).

# ? Jun 26, 2014 03:47

baby puzzle: Jun 3, 2011; I'll Sequence your Storm.

I'm not talking about rendering.. I.E. a state that has to do with the state of a mission/task/game state. We can potentially miss a state change that causes the client to become completely broken. These bugs can be very hard to reproduce. The correct solution is to register for callbacks on every state change from the network library.

# ? Jun 26, 2014 04:09

TheresaJayne: Jul 1, 2011

I was chatting with colleagues about bad code the other day,

One of them commented that in the source code they found the following comments

code:

/* 
eggs
cheese
bread
milk
potato
spaghetti
beans
butter
bacon
*/

obviously someone was coding whilst on the phone to their wife being given the weekly shop.

The bigger problem is that they committed it to SVN..

# ? Jun 26, 2014 07:50

qntm: Jun 17, 2009

I blame whoever buddy-checked it.

# ? Jun 26, 2014 12:26

TheresaJayne: Jul 1, 2011

qntm posted:

I blame whoever buddy-checked it.

Whats that!!!?

(Not currently an issue but apparently at the time they were actually old style waterfall....)
review = Does it work? Yes! = Code passed

# ? Jun 26, 2014 13:26

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

seiken posted:

So it's cool to add pointlessly, unnecessarily broken things to languages because you can always excuse it with well nobody should do that anyway.

Hey, it works for C++!

# ? Jun 26, 2014 14:05

substitute: Aug 30, 2003; you for my mum

Oh, let me just go check something in produ...

# ? Jun 26, 2014 16:51

seiken: Feb 7, 2005; hah ha ha

Hubis posted:

Hey, it works for C++!

There's a subtle difference. C++ adds new working things which renders old things pointlessly broken but insists on keeping them around anyway. Python intentionally adds obviously broken new things.

# ? Jun 26, 2014 17:20

Marta Velasquez: Mar 9, 2013; Good thing I was feeling suicidal this morning...; Fallen Rib

seiken posted:

There's a subtle difference. C++ adds new working things which renders old things pointlessly broken but insists on keeping them around anyway. Python intentionally adds obviously broken new things.

That's an homage to Monty Python's absurdist humor. Python users manage to be straight-faced while defending the illogicalities of a programming language.

# ? Jun 26, 2014 17:46

QuarkJets: Sep 8, 2008

seiken posted:

There's a subtle difference. C++ adds new working things which renders old things pointlessly broken but insists on keeping them around anyway. Python intentionally adds obviously broken new things.

I'm not even sure what we're talking about anymore. Are we still talking about nested for loops in list comprehensions?

# ? Jun 26, 2014 20:09

seiken: Feb 7, 2005; hah ha ha

QuarkJets posted:

I'm not even sure what we're talking about anymore. Are we still talking about nested for loops in list comprehensions?

who cares, everything is bad

# ? Jun 27, 2014 01:08

Spatial: Nov 15, 2007

I'm working on a compiler/vm for a scripting language which runs on an embedded microcontroller.

Whoever worked on it before me wrote the entire compiler in C in one 2500-line function, with no comments. All variables, of which there are only about 10, are declared at the top of this function and they're reused constantly. They are all single letter names. It runs without allocating memory for some reason. The compiler is intended to be run on a PC.

There is no error checking whatsoever, segfaulting is as good as it gets. Entire 50-line chunks are copied and pasted everywhere.

The only documentation is a list of #define'd opcodes with inscrutable four-letter names, and a virtual machine that runs exclusively on magic numbers with zero use of the defines.

Just amazing.

# ? Jun 27, 2014 01:38

pram: Jun 10, 2001

Spatial posted:

I'm working on a compiler/vm for a scripting language which runs on an embedded microcontroller.

Whoever worked on it before me wrote the entire compiler in C in one 2500-line function, with no comments. All variables, of which there are only about 10, are declared at the top of this function and they're reused constantly. They are all single letter names. It runs without allocating memory for some reason. The compiler is intended to be run on a PC.

There is no error checking whatsoever, segfaulting is as good as it gets. Entire 50-line chunks are copied and pasted everywhere.

The only documentation is a list of #define'd opcodes with inscrutable four-letter names, and a virtual machine that runs exclusively on magic numbers with zero use of the defines.

Just amazing.

I think you meant to post in the esoteric languages thread :mmmhmm:

# ? Jun 27, 2014 01:48

Hughlander: May 11, 2005

TheresaJayne posted:

I was chatting with colleagues about bad code the other day,

One of them commented that in the source code they found the following comments
code:
/* 
eggs
cheese
bread
milk
potato
spaghetti
beans
butter
bacon
*/
obviously someone was coding whilst on the phone to their wife being given the weekly shop.

The bigger problem is that they committed it to SVN..

A number of years ago there was a txt file with a woman's name and phone number in it. In the source code to the game engine. That we licensed to other studios. That predated the use of source control on the project and no one would own up to it.

# ? Jun 27, 2014 04:18

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 16:17

QuarkJets: Sep 8, 2008

Hughlander posted:

A number of years ago there was a txt file with a woman's name and phone number in it. In the source code to the game engine. That we licensed to other studios. That predated the use of source control on the project and no one would own up to it.

How do teams manage to start coding things like game engines without anyone yelling "HEY let's use source control for this huge project that we are about to undertake"

# ? Jun 27, 2014 05:34

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!

«‹›1503 »