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 »

gariig: Dec 31, 2004; Beaten into submission by my fiance; Pillbug

piratepilates posted:

Sourcesafe has got to be one of the biggest coding horrors, no branching support which makes it real fun when two people have to work on the same thing at once, or when someone commits changes to VSS but the changes aren't approve to make it to production and whoever works on that thing next doesn't check the status before grabbing the latest version.

You can branch in SourceSafe. I've never done it because it was very painful but it can be done. Also, you are criticizing software written over 20 years ago. Microsoft bought SourceSafe in 1994 and it was already a commercial product for a while (I couldn't find how long). It served a purpose back when most source control was still ZIP files or <project>_V## directories backed up on floppy disks.

Yes in 2013 using SourceSafe is a Coding Horror. Funny enough we still have two VB6 projects in SourceSafe that we haven't bothered to move over to TFS. We hardly touch them so not a huge deal.

# ? Jan 16, 2014 02:51

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 17:45

QuarkJets: Sep 8, 2008

Suspicious Dish posted:

I see this a lot. "An error came up, so we're just going to ignore it". I have to actually remove a lot of try/catch statements that should never happen in real life, but are only there to catch somebody else's bugs.

This reminds me of a thing that I get really annoyed at in Python development; there's this idea that you can just use try/except blocks to get some behavior that you want when that behavior should be obtained in another way. Maybe it would be okay if you were writing your own special snowflake Exception and catching only it and nothing else, but it's still loving stupid to intentionally throw exceptions just to mimic better code

I saw someone on stackoverflow suggesting that this:

Python code:

try:
    value = mydict["myvar"]
except:
    value = some_default

is perfectly fine and equivalent to this:

Python code:

if "myvar" in mydict:
    value = mydict["myvar"]
else:
    value = some_default

or this:

Python code:

value = mydict.get("myvar", some_default)

because they all give you the same result in a specific set of test cases.

# ? Jan 16, 2014 06:44

evensevenone: May 12, 2001; Glass is a solid.

Catching all exceptions is wrong, but

code:

try:
    value = mydict["myvar"]
except KeyError:
    value = some_default

is not appreciably different than the other two examples, and arguably more correct with a view toward duck typing.

# ? Jan 16, 2014 07:54

Jewel: May 2, 2009

evensevenone posted:

Catching all exceptions is wrong, but
code:
try:
    value = mydict["myvar"]
except KeyError:
    value = some_default
is not appreciably different than the other two examples, and arguably more correct with a view toward duck typing.

Aren't exceptions much slower than just checking iirc?

# ? Jan 16, 2014 08:38

evensevenone: May 12, 2001; Glass is a solid.

I don't think exceptions are particularly expensive. Certainly no style guide recommend against them.

And if the key exists, it's actually going to be faster than the second example.

# ? Jan 16, 2014 09:21

Scaevolus: Apr 16, 2007

dict.get exactly and explicitly matches the desired semantics of the operation. Anything else is less immediately obvious.

# ? Jan 16, 2014 09:24

..btt: Mar 26, 2008

Yeah, even if there is no performance impact, I think it's hard to defend using exceptions for anything other than exceptional circumstances. If you expect the key to sometimes not be present in the dictionary as part of normal operation, you should check for it, not use an exception (without an extremely compelling reason).

# ? Jan 16, 2014 10:02

Doctor w-rw-rw-: Jun 24, 2008

evensevenone posted:

I don't think exceptions are particularly expensive. Certainly no style guide recommend against them.

And if the key exists, it's actually going to be faster than the second example.

As a general rule for most any language, exceptions are expensive as gently caress when they are triggered, if they're optimized for very low overhead in the common, non-exceptional case. Style guides may recommend against exceptions in embedded/real-time software as they complicate timing analysis. And if the key exists, a typical data structure is going to have negligible difference in performance when checking for existence.

E: sorry. Missed the context of "Python". Exceptions might not be much slower on python, but it is emphatically the wrong solution for performance in general to rely on exceptions for normal flow control.

Doctor w-rw-rw- fucked around with this message at 10:25 on Jan 16, 2014

# ? Jan 16, 2014 10:23

Haystack: Jan 23, 2005

Python's core exceptions are about two-fold slower than and equivalent if loop in the worst case (source). I've heard scuttlebutt that custom exceptions are slower, but couldn't find anything to quantify it.

Best practice is to avoid using exceptions where the exception case is common. However, for rare or merely uncommon exceptions, try/except is considered more robust, and better semantics. It's less "You Should Always Ask For Forgiveness," and more "You Should Always Consider Asking For Forgiveness."

Haystack fucked around with this message at 16:38 on Jan 16, 2014

# ? Jan 16, 2014 14:56

SurgicalOntologist: Jun 17, 2004

Huh. I just wrote almost the exact same thing last night and thought I was being a good Python programmer for asking for forgiveness, not permission, or whatever.

I didn't use get because in my case the default value was complicated to figure out:

Python code:

try:
    value = mydict['key']
except KeyError:
    value = some_complicated_stuff(...)
    # set it as the value for next time
    mydict['key'] = value

The except clause will only occur once so I'm much more concerned with the performance of the original lookup. So it sounds like maybe this was the right choice performance-wise. I also think I commented well ("It's our first time encountering this key, so we have to figure out what it's value should be" in the except clause I think).

# ? Jan 16, 2014 15:23

nielsm: Jun 1, 2009

Sounds like you should have used a defaultdict there.

# ? Jan 16, 2014 16:55

seiken: Feb 7, 2005; hah ha ha

"Asking forgiveness instead of permission" is among the most terrible of all terrible nonsense "pythonic" rules. Exceptions are dynamic non-local gotos that obscure control-flow and spread the logic of your program across arbitrarily-distant functions. They should be used for exceptional circumstances and absolutely not as a matter of course. If you're forced to use exceptions for control-flow it's because Python is a bad language

# ? Jan 16, 2014 17:03

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

On the next exciting episode of programmersbeingdicks dot tumblr dot calm, "Python's 'Ask Forgiveness Instead of Permission' Policy and the perpetuation of Rape Culture among programmers"

# ? Jan 16, 2014 17:07

Macichne Leainig: Jul 26, 2012; by VG

seiken posted:

Exceptions are dynamic non-local gotos that obscure control-flow and spread the logic of your program across arbitrarily-distant functions.

Perhaps even more stupid about this specific example is the fact that if an exception is encountered you go to literally the next line. Regardless of how stupid exception handling is in this case, if you're trying only one line of code that isn't even an explicit method, there's probably a better way to do it (like dict.get.)

# ? Jan 16, 2014 17:09

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Well it's not like you're forced to use exceptions as a control flow mechanism in any common language facilities in Python...

http://docs.python.org/2/library/exceptions.html#exceptions.StopIteration

Oh.

# ? Jan 16, 2014 17:14

..btt: Mar 26, 2008

I've barely touched Python. Is that as much of a horror as it appears to be? Does Python really have that much of a different concept of exceptions than all the other languages I have used?

# ? Jan 16, 2014 17:19

SurgicalOntologist: Jun 17, 2004

nielsm posted:

Sounds like you should have used a defaultdict there.

I forgot to mention that when a new key is encountered, I reassign all the other keys as well.

I guess I'll explain since there's a reasonable chance I'm the horror and I wouldn't mind learning. I'm interfacing with a bunch of wireless sensors that are numbered but otherwise identical. If the user writes an application using two sensors, they probably need to know which is which. And yet, they might use sensor 1 and sensor 2, but then the batteries run out and they switch to 3 and 4. And maybe the next day sensor 2 is broken and they use 1 and 3. I can't require the user to always use, e.g., sensors 1 and 2. I don't want the user to have to input the sensor numbers every time they start a new session because that will inevitably cause fuckups. But the sensors still need to be identifiable within each session.

My solution is that every time data comes in from a new sensor, I resort the existing sensor numbers and "mydict" in the snippet above is a mapping from internal sensor numbers to external sensor numbers. For the user, their application can refer to sensor 0 and sensor 1 and all they have to worry about when using their application is the relative ordering of the actual sensor numbers. Data comes in at 200 Hz so getting the sensor numbers wrong for the first 1/200 s is not a big deal, and after that speed is important.

SurgicalOntologist fucked around with this message at 17:35 on Jan 16, 2014

# ? Jan 16, 2014 17:32

nielsm: Jun 1, 2009

So have one thing that generates a sensor_logical_physical_map from scratch, a flag that specifies that the current map is invalid for some reason, something that sets that flag as appropriate (startup, error condition detected), and check that flag once a cycle? Basically the straight forward way you'd have written it in C 30 years ago.

# ? Jan 16, 2014 17:45

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

..btt posted:

I've barely touched Python. Is that as much of a horror as it appears to be?

quote:

Does Python really have that much of a different concept of exceptions than all the other languages I have used?

Yes(-ish), but that doesn't necessarily make it a horror. They should probably have a different name in Python so people don't freak out when they're used the way they are because they're used for control flow and that's Very Bad in every other language I know of that supports the concept. It freaked me out at first, but it works fine when not abused as shown above (not calling out SugicalOntologist - the stuff further up), so eh. In my fantasy Python 4M, they're called signals or interrupts - something like that.

# ? Jan 16, 2014 17:49

SurgicalOntologist: Jun 17, 2004

nielsm posted:

So have one thing that generates a sensor_logical_physical_map from scratch, a flag that specifies that the current map is invalid for some reason, something that sets that flag as appropriate (startup, error condition detected), and check that flag once a cycle? Basically the straight forward way you'd have written it in C 30 years ago.

So... pretty much the same except the Except clause sets a flag instead, and the map is fixed elsewhere?

There's only one applicable condition, when I first encounter a sensor that hasn't been mapped. On startup I haven't yet encountered any sensors (each cycle I only get data from one sensor. With more sensors the cycles come faster).

# ? Jan 16, 2014 17:54

seiken: Feb 7, 2005; hah ha ha

Munkeymon posted:

No

Yes(-ish), but that doesn't necessarily make it a horror. They should probably have a different name in Python so people don't freak out when they're used the way they are because they're used for control flow and that's Very Bad in every other language I know of that supports the concept. It freaked me out at first, but it works fine when not abused as shown above (not calling out SugicalOntologist - the stuff further up), so eh. In my fantasy Python 4M, they're called signals or interrupts - something like that.

There's not really any reason it would be less of a horror in Python. If you don't abuse it and only catch the exception one level up as above of course that's not too bad, but when you start depending on control-flow like that it's inevitable the catches will start moving further and further away from the raises and the program will become harder to reason about locally.

vvv that's ridiculous, naming has nothing to do with it. Control flow exceptions are poo poo no matter what the language is or what they're called

seiken fucked around with this message at 18:52 on Jan 16, 2014

# ? Jan 16, 2014 18:03

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

seiken posted:

There's not really any reason it would be less of a horror in Python. If you don't abuse it and only catch the exception one level up as above of course that's not too bad, but when you start depending on control-flow like that it's inevitable the catches will start moving further and further away from the raises and the program will become harder to reason about locally.

Just having exceptions at all allows that to happen, though. I've seen C# that used exceptions to transition between UI states using exceptions like DownloadSuccessfulException, for example.

Python is structured to lean on them more heavily than most languages, but that's intentional, so it's helpful to think of them as a misnamed feature instead of a misapplied tool. Basically, complaining that Python uses exceptions 'wrong' is, to some extent, about as useful as complaining that it treats types 'wrong' because it doesn't check them at the start of the function like some other languages.

# ? Jan 16, 2014 18:50

evensevenone: May 12, 2001; Glass is a solid.

I just deal with a lot of programmers who are like pathologically terrified of exceptions and waste tons of time coding around corner cases that raise exceptions.

I also come from the C world where the "pass a pointer to where you want the results of the function as a parameter, then check the return value of the function to see if it worked, and then check errno to see where it went wrong" style is prevalent and holy god does that get old.

# ? Jan 16, 2014 18:51

..btt: Mar 26, 2008

Munkeymon posted:

Just having exceptions at all allows that to happen, though. I've seen C# that used exceptions to transition between UI states using exceptions like DownloadSuccessfulException, for example.

I guess the difference is that in the .net world this is objectively stupid and wrong, since there is such a large overhead to throwing an exception, and convention dictates you do not use exceptions for flow control (except, of course, when dealing with exceptional circumstances such as unexpected errors).

Like any rule, there are exceptions ( :v:

), but in the vast majority of cases the above is true. A value not being in a dictionary in the detailed example above is likely to happen in normal operation, so in this instance an exception should not be used. I would expect the Dictionary.Get function to throw an exception if the value wasn't there - this is entirely appropriate, particularly when "null" or "-1" or whatever could be valid return values. I would not expect code calling the dictionary to throw an exception, but to preface the call with a .ContainsKey guard.

# ? Jan 16, 2014 19:06

Damiya: Jul 3, 2012

Munkeymon posted:

Just having exceptions at all allows that to happen, though. I've seen C# that used exceptions to transition between UI states using exceptions like DownloadSuccessfulException, for example.

This is a true horror like God drat

# ? Jan 16, 2014 19:11

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

I usually hear those referred to as "Expections".

# ? Jan 16, 2014 19:20

QuarkJets: Sep 8, 2008

SurgicalOntologist posted:

Huh. I just wrote almost the exact same thing last night and thought I was being a good Python programmer for asking for forgiveness, not permission, or whatever.

I didn't use get because in my case the default value was complicated to figure out:
Python code:
try:
    value = mydict['key']
except KeyError:
    value = some_complicated_stuff(...)
    # set it as the value for next time
    mydict['key'] = value
The except clause will only occur once so I'm much more concerned with the performance of the original lookup. So it sounds like maybe this was the right choice performance-wise. I also think I commented well ("It's our first time encountering this key, so we have to figure out what it's value should be" in the except clause I think).

It's generally poor practice and isn't actually faster:

Python code:

def test(mydict):
    if "val" in mydict:
        x = mydict["val"]
    else:
        x = 11
        
import timeit
print timeit.timeit("test(test_dict)", 
                setup="from __main__ import test; test_dict = { 'val' : 5}",
                number=1000000)

That function executes in 0.1516s when the key is in the dict, or 0.135s when it isn't

Python code:

def test(mydict):
    try:
        x = mydict["val"]
    except KeyError:
        x = 11
        
import timeit
print timeit.timeit("test(test_dict)", 
                setup="from __main__ import test; test_dict = { 'val' : 5}",
                number=1000000)

That function executes in 0.1522s when the key is in the dict, or 1.14s when it isn't. Performance-wise, the try/except block is almost ten times slower when the key is missing, but it's about the same speed when the key is present.

Don't use exceptions for flow control, it's a stupid and expensive practice

seiken posted:

"Asking forgiveness instead of permission" is among the most terrible of all terrible nonsense "pythonic" rules. Exceptions are dynamic non-local gotos that obscure control-flow and spread the logic of your program across arbitrarily-distant functions. They should be used for exceptional circumstances and absolutely not as a matter of course. If you're forced to use exceptions for control-flow it's because Python is a bad language

You are never forced to use Exceptions for flow control, even if some people think that exception-based flow control is cool for some reason. Python is a good language used by bad people who sometimes like to misuse useful tools

QuarkJets fucked around with this message at 19:50 on Jan 16, 2014

# ? Jan 16, 2014 19:40

BigRedDot: Mar 6, 2008

QuarkJets posted:

It's generally poor practice and isn't actually faster:
Python code:
def test(mydict):
    if "val" in mydict:
        x = mydict["val"]
    else:
        x = 11
        
import timeit
print timeit.timeit("test(test_dict)", 
                setup="from __main__ import test; test_dict = { 'val' : 5}",
                number=1000000)
That function executes in 0.1516s when the key is in the dict, or 0.135s when it isn't
Python code:
def test(mydict):
    try:
        x = mydict["val"]
    except KeyError:
        x = 11
        
import timeit
print timeit.timeit("test(test_dict)", 
                setup="from __main__ import test; test_dict = { 'val' : 5}",
                number=1000000)
That function executes in 0.1522s when the key is in the dict, or 1.14s when it isn't. Performance-wise, the try/except block is almost ten times slower when the key is missing, but it's about the same speed when the key is present.

Don't use exceptions for flow control, it's a stupid and expensive practice

You are never forced to use Exceptions for flow control, even if some people think that exception-based flow control is cool for some reason. Python is a good language used by bad people who sometimes like to misuse useful tools

To be completely truthful, it's a little more complicated than this analysis. Whether or not using exceptions vs interrogating is faster depends on the rate of misses.

code:

def testif(d, N, miss_rate):
    M = int(len(d)/(1-miss_rate))
    for x in xrange(N):
        for i in xrange(M):
            if i in d:
                x = d[i]
            else:
                x = i

def testtry(d, N, miss_rate):
    M = int(len(d)/(1-miss_rate))
    for x in xrange(N):
        for i in xrange(M):
            try:
                x = d[i]
            except KeyError:
                x = i

d = { i:i for i in xrange(10000) }

With a higher miss_rate, the exception version does much worse:

code:

IIn [37]: %timeit testif(d, 100, 0.2)
10 loops, best of 3: 106 ms per loop

In [38]: %timeit testtry(d, 100, 0.2)
1 loops, best of 3: 215 ms per loop

However, with a very low miss_rate, the exception version is actually appreciably faster:

code:

In [39]: %timeit testif(d, 100, 0.0001)
10 loops, best of 3: 93.9 ms per loop

In [40]: %timeit testtry(d, 100, 0.0001)
10 loops, best of 3: 71.2 ms per loop

I think perhaps there's a case to be made that something that only happens a hundredth of one percent of the time might reasonably be called "exceptional". Regardless of your opinion about semantics, however, if you are chasing performance, a one-size-fits-all rule will not work; you have to consider your expected miss rate, if it is available. IIRC the "break-even" cutoff is around eight percent.

BigRedDot fucked around with this message at 21:33 on Jan 16, 2014

# ? Jan 16, 2014 21:26

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

Munkeymon posted:

Python is structured to lean on them more heavily than most languages, but that's intentional, so it's helpful to think of them as a misnamed feature instead of a misapplied tool. Basically, complaining that Python uses exceptions 'wrong' is, to some extent, about as useful as complaining that it treats types 'wrong' because it doesn't check them at the start of the function like some other languages.

I'd have to agree with seiken here, the naming isn't the problem. Python calls them exceptions because they behave like exceptions; i.e. they halt control flow, unwind the stack, and jump to the nearest handler. That is an expensive operation and it's the primary reason why exceptions are considered a horror for control flow. Calling it something else doesn't change the nature of the underlying mechanism nor the reasons why it's a bad idea.

# ? Jan 16, 2014 21:41

Tesseraction: Apr 5, 2009

BigRedDot posted:

To be completely truthful, it's a little more complicated than this analysis. Whether or not using exceptions vs interrogating is faster depends on the rate of misses.

I think perhaps there's a case to be made that something that only happens a hundredth of one percent of the time might reasonably be called "exceptional". Regardless of your opinion about semantics, however, if you are chasing performance, a one-size-fits-all rule will not work; you have to consider your expected miss rate, if it is available. IIRC the "break-even" cutoff is around eight percent.

I'd assume QuarkJets meant using it in place of an if statement, not never using it. I'd surround attempts at reading files with an try/except but if I wanted to use a variable that may or may not be empty/null then I wouldn't do

code:

foo = bar()

try:
    foo += baz
except TypeError:
    foo = baz

when 'if foo:' would suffice.

Looking before you leap is best in most scenarios but as you say, if the failure case truly is exceptional then that's where a try/except comes into play.

# ? Jan 16, 2014 21:52

BigRedDot: Mar 6, 2008

Tesseraction posted:

I'd assume QuarkJets meant using it in place of an if statement, not never using it.

Well but that was the point, if you are doing it in a loop that has 10 million iterations, and you only expect it to fail 10 times, then you absolutely should use try: except: in place of an if statement if you want it to be as fast as possible.

BigRedDot fucked around with this message at 22:03 on Jan 16, 2014

# ? Jan 16, 2014 21:56

SurgicalOntologist: Jun 17, 2004

Okay, I'm sticking with try/except then, my miss rate is something like 1 in 1 million.

# ? Jan 16, 2014 22:05

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Monkeyseesaw posted:

I'd have to agree with seiken here, the naming isn't the problem. Python calls them exceptions because they behave like exceptions; i.e. they halt control flow, unwind the stack, and jump to the nearest handler. That is an expensive operation and it's the primary reason why exceptions are considered a horror for control flow. Calling it something else doesn't change the nature of the underlying mechanism nor the reasons why it's a bad idea.

I get all of that and I've been on your side of this same argument - probably back a few years in this thread - but the people who maintain the language use them for flow control and I'm giving them the benefit of the doubt and trying not to worry about it.

# ? Jan 16, 2014 22:08

QuarkJets: Sep 8, 2008

SurgicalOntologist posted:

Okay, I'm sticking with try/except then, my miss rate is something like 1 in 1 million.

In your circumstance, there is already a tool written into the language that does exactly what you want to do. You should either use dict.get() or a defaultdict for more complicated cases

try/except with careful crafting (IE catching the exact exception that you want and having an extremely short try block) is not a horror, but it is a slippery slope to horrors that you should avoid when there's already a mechanism that does the same thing in a better way

# ? Jan 17, 2014 01:30

SurgicalOntologist: Jun 17, 2004

QuarkJets posted:

In your circumstance, there is already a tool written into the language that does exactly what you want to do. You should either use dict.get() or a defaultdict for more complicated cases

Maybe I'm missing something but I don't see how I could accomplish what I'm doing with a defaultdict. Every time I encounter a missing key I'm not only supplying the missing value but also changing the value of all the existing elements in the dict.

# ? Jan 17, 2014 01:36

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

Why do you want to modify an entire dict when a key is missing?

# ? Jan 17, 2014 01:49

QuarkJets: Sep 8, 2008

SurgicalOntologist posted:

Maybe I'm missing something but I don't see how I could accomplish what I'm doing with a defaultdict. Every time I encounter a missing key I'm not only supplying the missing value but also changing the value of all the existing elements in the dict.

Hmm, I reread your later posts and that's true

But I guess I don't understand why you're using a dict at all, in that case. If you're just using the keys "Sensor1", "Sensor2", ..., "SensorN" and then remapping other objects to these keys, why not just use a list of length N? Then the user just references an entry in the list rather than referencing the "SensorN" key in the dictionary.

e: I guess I don't really understand your setup that well. Can you describe it again? Clearing and then re-instantiating the dict every time that you see a new sensor sounds like a lot of unnecessary work

QuarkJets fucked around with this message at 01:58 on Jan 17, 2014

# ? Jan 17, 2014 01:51

SurgicalOntologist: Jun 17, 2004

The issue is how to allow the user to select any set of sensors while also making them predictably identifiable. Basically, I need to map physical sensors to logical sensors as someone said.

For an example, maybe you're using these sensors to make a two-player game. One player controls a "goalie" (I'm visualizing a pong paddle) and the other player tosses projectiles toward the goal by making a flicking motion. I want the players to be able to pick any two physical sensors but still be able to predict which will control the goalie and which will control the shooter. The solution being that only the relative order of the sensor numbers matters: maybe whoever has the sensor with the lower number is the goalie.

I want to end up with a dict that has physical sensor numbers as keys and logical sensor numbers as values. When raw data comes in, I clean it up, extract the sensor number, and use that to determine where to store the rest of the data:

Python code:

physical_sensor = data.pop('sensor', 0)  # Devices with only a single sensor don't send a sensor number
logical_sensor = physical_to_logical_sensor_map[physical_sensor]  # this is the line in the try clause but this
                                                                  # just demonstrates how it works once I have the map
data_by_sensor[logical_sensor] = data  # data_by_sensor is indeed a list and is what the user will access, 
                                       # the other stuff will be hidden

Each sensor sends data in a constant 200 Hz stream and the same set of sensors is used in a single session. So after the first 5 ms I already know which sensors I'll be seeing for the rest of the session. The first cycle goes like this:
1. A data packet comes in. Call this sensor 0. At this point we have no idea if we will encounter more sensors, and if so what physical numbers they will have.
2. Another data packet comes in. If it's from the same sensor, we're good for the rest of the session. If it's from a new sensor, reorder the sensors. Make the one with a lower physical number sensor 0.
3. Etc. until the first cycle has completed.
4. After 5 ms the sensor mapping should be stable for the rest of the session.

The only downside is before 5 ms have passed the data will be misidentified. But I'm not too concerned about that.

Anyways I think I have this figured out I only posted it because someone posted catching a KeyError for control flow as a horror within 8 hours of my having done exactly that.

E: I suppose I could avoid the try-except by sending data to a 'set_up_sensors' procedure until the first cycle completes, at which point I switch the data stream to send to the normal handler. Only issue here is I'm not confident in the hardware - there's a chance I could get a second packet from one sensor before I get the first packet from another. I suppose I could transition after like 50 ms or something to be absolutely confident, but setting that up would be more effort than it's worth, I think.

SurgicalOntologist fucked around with this message at 06:26 on Jan 17, 2014

# ? Jan 17, 2014 06:17

TransatlanticFoe: Mar 1, 2003; Hell Gem

I think the person that was on my team before I got there had this whole Python exception handling thing down, found a bunch of code like this today:

code:

def updateUser(request):
    try:
        # 400 lines of code eventually returning an HttpResponse object
    except Exception:
        traceback.print_exc()

# ? Jan 17, 2014 06:27

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 17:45

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

SurgicalOntologist posted:

The only downside is before 5 ms have passed the data will be misidentified. But I'm not too concerned about that.

Most of what you're saying makes sense, but this specifically is really weird. You're being blas� about, basically, introducing an arbitrary and unnecessary source of data corruption to your clients, who may or may not care about the sensors having nice, small identifying numbers but definitely care a lot about reliably identifying a single stream of data. If the renumbering thing is really important for some reason you haven't explained, then yes, you almost certainly should just delay/suppress sending any data to the client for the first cycles until you've figured out how many sensors there are.

# ? Jan 17, 2014 07:30

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 »