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 »

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

Ask him where the persistence is

# ? Oct 26, 2015 16:23

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 18:26

loinburger: Jul 10, 2004; Sweet Sauce Jones

While in the middle of crashing, the server saves the uncommitted JMS transaction to disk

# ? Oct 26, 2015 16:28

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

I didn't realize JMS was itself persistent. You said it wasn't doing disk IO at all.

# ? Oct 26, 2015 16:41

loinburger: Jul 10, 2004; Sweet Sauce Jones

JMS needs the disk for persistence (or there might be some way to use some sort of distributed network cache or whatever, but that doesn't matter since right now this program is only running on one server). I suspect that my co-worker either doesn't know what "persistent" means, or he doesn't know what "transaction" means, or both.

# ? Oct 26, 2015 16:56

Karate Bastard: Jul 31, 2007; Soiled Meat

Well of course it's persistent, it says so in the name, right there: "persistent". Any more questions?

# ? Oct 26, 2015 17:01

Space Kablooey: May 6, 2009

loinburger posted:

While in the middle of crashing, the server saves the uncommitted JMS transaction to disk

Well, we can save the transaction if we put a try/catch aro- :commissar:

# ? Oct 26, 2015 17:11

canis minor: May 4, 2011

loinburger posted:

JMS needs the disk for persistence (or there might be some way to use some sort of distributed network cache or whatever, but that doesn't matter since right now this program is only running on one server). I suspect that my co-worker either doesn't know what "persistent" means, or he doesn't know what "transaction" means, or both.

You already know under which situations the problem will arise, so I guess there shouldn't be a problem with explaining it to him?

Meanwhile, I've spotted my first !$var == in the wild.

# ? Oct 26, 2015 17:26

loinburger: Jul 10, 2004; Sweet Sauce Jones

canis minor posted:

You already know under which situations the problem will arise, so I guess there shouldn't be a problem with explaining it to him?

There shouldn't be, but evidently there is due to some combination of my failing to make myself clear and him being dense. I've given him some code to run that will hopefully convince him that there's a problem: send an item to the queue, take the item off the queue, start processing the item, call System.exit in the middle of processing, check to see if the item is still on the queue after restarting the program.

# ? Oct 26, 2015 17:46

ryde: Sep 9, 2011; God I love young girls

I think this is more of a "dense" thing than "not being clear" thing. It's pretty obvious why your coworkers idea is bad.

# ? Oct 26, 2015 20:50

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

loinburger posted:

My co-worker wants to "optimize" this
1. Item is enqueued in ActiveMQ using a JMS transaction; we don't commit this transaction
2. Eventually we take the item out of the queue and process it using the same JMS transaction that we used to enqueue the item
3. If nothing goes wrong then we commit the JMS transaction which doesn't make any changes to the queue, if the server crashes in the meantime then the item is gone forever because we never committed the transaction that sends the item to ActiveMQ

This way everything runs faster because we're not doing disk IO! He insists that this will still behave like a persistent queue (I'm trying to convince him that this is wrong) - I'm not sure how we can have a persistent queue without doing disk IO, but there you go.

Always turn stupidity/ignorance into work for the target. "Oh that's great, but just to be sure can you go write a program that uses this method and ends in the middle? You know, just to be sure the transactions will be saved. It's just a quick test program, it shouldn't take long".

If they're an idiot, then you stopped them from writing production code for a day.

If they're just ignorant then they'll hopefully learn something about how the system works and be a better programmer for it.

# ? Oct 27, 2015 00:00

TheresaJayne: Jul 1, 2011

this one is like Crazy,

I was viewing Facebook, and I clicked a story to go read and got this page, Full debug and source code view of calls.

http://look.checkthisyo.com/having-bad-day/?mb=grvcty&utm_term=badd&v=2&utm_source=d32f28bf8764c69c6310d370fe17788f&utm_campaign=campaign-4

edit : looks like they fixed it now, this is what i was getting:

# ? Oct 27, 2015 09:42

Karate Bastard: Jul 31, 2007; Soiled Meat

Well, Subjunctive, you know the deal. Give us the horror.

# ? Oct 27, 2015 10:29

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

I wondered about that too, but the broken link was found on FB rather than being an FB page, I believe. (Our paths don't look like that, nor error pages.)

# ? Oct 27, 2015 10:31

SupSuper: Apr 8, 2009; At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

Honestly that's the prettiest PHP error log I've ever seen.

Shame about the useless autogenerated docs though. :v:

# ? Oct 27, 2015 10:45

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

That's from Laravel, probably version 4.2.

Anyway, that's what displays when you have debug mode turned on and your app isn't in production.

# ? Oct 27, 2015 11:39

Slash: Apr 7, 2011

Blinkz0rz posted:

That's from Laravel, probably version 4.2.

Anyway, that's what displays when you have debug mode turned on and your app isn't in production.

... or is in Production apparently.

# ? Oct 27, 2015 11:41

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Sorry, the environment isn't set to production. You know what I meant.

# ? Oct 27, 2015 11:49

KernelSlanders: May 27, 2013; Rogue operating systems on occasion spread lies and rumors about me.

The real horror is everything about that clickbait site.

# ? Oct 27, 2015 14:14

Sedro: Dec 31, 2008

SupSuper posted:

Honestly that's the prettiest PHP error log I've ever seen.

Shame about the useless autogenerated docs though.

I used an API with docs like that. The entire documentation is generated from the function/parameter/class names. setThing() sets the thing, doThing(status) does the thing. What's status? the status.

My favorite:

quote:

getMimeType(): gets the type of mime

# ? Oct 27, 2015 16:33

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

"Hey Mogomra, some poo poo I wrote was throwing errors for no real reason yesterday. Can you check it out?"

code:

/var/app/current/server.js:74
	throw(e);
	      ^
SyntaxError: Unexpected token r
    at Object.parse (native)
    at IncomingMessage.<anonymous> (/var/app/current/server.js:34:13)
    at IncomingMessage.emit (events.js:104:17)
    at _stream_readable.js:908:16
    at process._tickCallback (node.js:355:11)
...

Well will you look at that. Blindly JSON parsing raw user input, ignoring the fact that it throws errors. What else is new? I see my coworkers do this all day every day.

I open up server.js, and poo poo starts jumping out at me left and right.

For one, it's storing an entire "database" in memory. It contains a list of store numbers, store addresses, and store latitude and longitude values. Oh yeah, and it's redefined one time per request to this server. Oooh yeah, and it's all defined on one 15 thousand character long line... Hey, whatever, that's not what's breaking this poo poo.

Here we go, line 34 is the offending JSON.parse. Wait a minute...

JavaScript code:

try{
			req=JSON.parse(request.app.data);

			

			// ...
			// Do some work
			// ...

}catch(e){
	throw(e);

	// EVEN. MORE. CODE.
}

For real? What was the thought process here? Like, ok, try catch some lovely JSON parsing... Then immediately throw the error anyway! One step forward, two steps back.

I know this is pretty common in this thread, but I just wanted to let everyone know that they're not alone. The infamous try, catch, throw is alive and well.

E: Updated quote with real words that were written by the person who wrote the server.js in question to describe this task to me.

Mogomra fucked around with this message at 21:19 on Oct 27, 2015

# ? Oct 27, 2015 21:10

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Try, catch, throw isn't necessarily an antipattern. If you wrap the exception (more for Java) or you do some work before you rethrow, it can be useful.

Doing work in the catch block AFTER the rethrow, of course, is right out.

# ? Oct 27, 2015 21:21

Karate Bastard: Jul 31, 2007; Soiled Meat

Well it does beat try, catchall, carry on then broken state.

# ? Oct 27, 2015 21:21

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

If you want to do work then rethrow, you might want finally instead.

# ? Oct 27, 2015 22:07

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

It could be worse, yeah, but in this case there was just no point to any of it. The extra code after the throw was more error logging.

And the fact that he designed it specifically to blow up, and then came to me all like, "Well there's no reason it should be doing this" gave me the biggest "WTF" moment I've had in a long time.

It's an HTTP server that's expecting JSON requests. If the request is invalid JSON, or not JSON at all, why aren't you doing something sane like sending 4xx responses instead of flat out crashing and burning? This is apparently our company's bread and butter, but I see this poo poo all the time.

I believe the words, "Maybe there's a bug in Node.js" were spoken as well. Just real :psyduck:

poo poo.

# ? Oct 27, 2015 22:17

MrMoo: Sep 14, 2000

Well, there probably is more than one bug is node.js too, but they're not in a position to prove it either way.

# ? Oct 27, 2015 22:28

loinburger: Jul 10, 2004; Sweet Sauce Jones

Some exception handling/logging crap I often see is

code:

public void a() {
    try {
        b();
    } catch(Exception e) {
        log(e.getMessage(), e);
    }
}

private void b() throws Exception {
    try {
        c();
    } catch(Exception e) {
       log(e.getMessage, e);
       throw(e);
    }
}

private void c() throws Exception {
    try{
        d();
    } catch(Exception e) {
        log(e.getMessage(), e);
        throw(e);
    }
}

and so on. We wind up with one exception getting logged several times, which does not help at all when diagnosing the problem.

# ? Oct 27, 2015 22:38

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

loinburger posted:

We wind up with one exception getting logged several times, which does not help at all when diagnosing the problem.

We avoid that problem by not logging anything.

# ? Oct 27, 2015 22:44

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Bognar posted:

We avoid that problem by not logging anything.

Also avoids issues with logging impact on performance, or having to spend time looking in logs when something goes wrong. Strong move.

# ? Oct 27, 2015 23:17

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

Hammerite posted:

Why would you turn it into a #define rather than a const variable?

Missed this question.

For simple bits, no big deal either way. The gotcha is something that has a few different selectors placed in different bit offsets, but all with the same meaning. Clock select is a common one.

code:

#define CLOCK_MAIN          0
#define CLOCK_PERIPH        1
#define CLOCK_IO            2
#define CLOCK_EXTERNAL      3

#define INPUT_CLOCK(x)  (((x)&0x03) << 3)
#define OUTPUT_CLOCK(x) (((x)&0x03) << 0)
...

    SetReg(CLOCK_CTRL, CLOCK_INPUT(CLOCK_MAIN)|CLOCK_OUTPUT(CLOCK_IO));

or possibly

    SetReg(CLOCK_CTRL, CLOCK_INPUT(input_clock)|CLOCK_OUTPUT(output_clock));

For lowlevel hardware, it's critical that you can tell what something is doing at a glance. That means not having to decode a magic hex constant inline. It also means trusting your headers - but that's the least likely source of bugs. The most common error I've seen is an inline hex constant with a detailed comment explaining exactly what it sets - but the two aren't in sync anymore.

Ideally, we wouldn't have 40 different settings crammed into 3 bytes of registers (In some fun hardware, setting say SYNC_MODE vs ASYNC_MODE completely changes the meanings and layouts of the other registers) but tiny parts consider their 256*8 register bits an extremely scarce resource (that they use 50 of, max).

Minor horror: Either idea or android lint is encouraging goto fail; - it's flagging warnings wherever I brace around a single-statement if/for. Haven't figured out how to disable that one either since it helpfully doesn't include a warning code for such a "simple" popup, and the actual wording plugged into google only brings up the style war.

# ? Oct 28, 2015 01:20

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

We have Pokemon exception handling at work. Every single method - and I do mean every single one - is structured as

code:

Try
    ' do stuff here
Catch ex As Exception
    WriteLog("ModuleName", "MethodName", "An error happened while fooing the bar!", ex.ToString, showPopUp:=true, {bunch of optional arguments for error level etc.})
    MethodName = 'set return value to a default failure value
End Try

Most of the time it doesn't work too badly. It's boilerplate-y as gently caress, but I have a CodeRush macro to add it automatically and with VB14's NameOf() operator I may be able to get rid of a couple of those arguments without the need for reflection.

The problem happens when you have this:

code:

     For Each product in Products()
          RefreshProduct()
     Next

If there's an exception that happens in RefreshProduct() because of a corrupt db table or whatever, and the showPopUp in RefreshProduct()'s catch block was set to True (because it's a method that normally gets invoked on one article at a time, for example), the user is going to enjoy a nice series of 27000 "There was an error while refreshing a product!" popups.

So every time you write a loop, you have to check the implementation of every function you call and make sure it's "silent", and if it isn't you must add an extra argument to make it avoid any popups.

# ? Oct 28, 2015 05:49

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

Harik posted:

Missed this question.

For simple bits, no big deal either way. The gotcha is something that has a few different selectors placed in different bit offsets, but all with the same meaning. Clock select is a common one.

...

For lowlevel hardware, it's critical that you can tell what something is doing at a glance. That means not having to decode a magic hex constant inline. It also means trusting your headers - but that's the least likely source of bugs. The most common error I've seen is an inline hex constant with a detailed comment explaining exactly what it sets - but the two aren't in sync anymore.

I still don't understand why you'd use #define rather than using const variables for the constants and functions for the macros-with-arguments.

I have seen this behaviour of going and modifying code that has comments, and yet not modifying the comments, at my company. It dismays me very much, because I think comments explaining non-obvious aspects of the code are very good things to have, and yet if people are going to make changes that render the comments inaccurate then they become a liability. Obviously the ideal solution is to not have code that has non-obvious aspects, but sometimes that isn't possible. I think at the end of the day I still feel that the comments should be present and if someone edits the code but doesn't update relevant comments then they should be shouted at - it should be seen to be as bad as committing code that doesn't work correctly.

# ? Oct 28, 2015 11:23

Soricidus: Oct 21, 2010; freedom-hating statist shill

Hammerite posted:

I still don't understand why you'd use #define rather than using const variables for the constants and functions for the macros-with-arguments.

Why wouldn't you? Macros are just as clear in this case, and are guaranteed to produce optimal code, which is desirable in this kind of context. What tangible benefits does the alternative offer?

# ? Oct 28, 2015 11:52

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

Soricidus posted:

Why wouldn't you? Macros are just as clear in this case, and are guaranteed to produce optimal code, which is desirable in this kind of context. What tangible benefits does the alternative offer?

Type-safety, primarily. Less error-prone, because the compiler can check that you're invoking the function correctly. The IDE will be better at helping you out (at least, MSVS is hopeless at macros; I assume other IDEs are similarly better at supporting code that doesn't make heavy use of macros, because macro-expansion is hairy to make sense of*). Assuming a reasonable compiler, there should be no difference after compilation, so I don't follow your "optimal code" statement.

* Having "programmed" in TeX in the past, I am very wary of making use of macro expansion when there are better alternatives available.

# ? Oct 28, 2015 12:07

Volte: Oct 4, 2004; woosh woosh

Soricidus posted:

Why wouldn't you? Macros are just as clear in this case, and are guaranteed to produce optimal code, which is desirable in this kind of context. What tangible benefits does the alternative offer?

For the 'functions' this may well be true, but inlining constant variables is something that even baby's first compiler can usually do, so the answer is either "consistency" or "because gently caress you". There's no real good reason to use macro defines for literal values. And there is a reason not to: they can be easily clobbered by redefining them in another (or third party) header file, which may cause your compilation to fail for unknown reasons (if the redefinition is not compatible) or it may make your program do surprising things for nigh undiagnosable reasons. People like strong, static typing for this reason, but even a little lexical scoping and redefinition warnings can go a long way. Preprocessor macros are the ultimate gently caress-you to the compiler.

# ? Oct 28, 2015 12:11

feedmegin: Jul 30, 2008

Volte posted:

For the 'functions' this may well be true, but inlining constant variables is something that even baby's first compiler can usually do

It's not guaranteed or required to, though, especially if you're doing a non-optimised debug build or whatever. Relying on the optimiser to do a specific thing rather than the language standard isn't really a good idea.

# ? Oct 28, 2015 12:31

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Especially when you consider compilers for embedded platforms can vary wildly in quality and may consider "optimization" to be the same thing as "well, we'll just strip out the debug information".

# ? Oct 28, 2015 12:46

Volte: Oct 4, 2004; woosh woosh

Why bother using functions at all

# ? Oct 28, 2015 12:47

Volte: Oct 4, 2004; woosh woosh

Someone just unironically told me it's a bad idea to rely on constants and that you should always use preprocessor macros in order to prematurely optimize. Am I in the coding horrors thread or what?

# ? Oct 28, 2015 12:49

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Hammerite posted:

Type-safety, primarily. Less error-prone, because the compiler can check that you're invoking the function correctly. The IDE will be better at helping you out (at least, MSVS is hopeless at macros; I assume other IDEs are similarly better at supporting code that doesn't make heavy use of macros, because macro-expansion is hairy to make sense of*). Assuming a reasonable compiler, there should be no difference after compilation, so I don't follow your "optimal code" statement.

* Having "programmed" in TeX in the past, I am very wary of making use of macro expansion when there are better alternatives available.

I share your distaste for macros, but why do they pose a problem for IDEs? If they can run the compiler in the background to type check your code, I don't see why it would be any harder to run the preprocessor followed by the compiler instead.

# ? Oct 28, 2015 13:04

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 18:26

Athas: Aug 6, 2007; fuck that joker

NihilCredo posted:

I share your distaste for macros, but why do they pose a problem for IDEs? If they can run the compiler in the background to type check your code, I don't see why it would be any harder to run the preprocessor followed by the compiler instead.

Mapping the preprocessor-generated code back to the source text may not be trivial.

# ? Oct 28, 2015 13:49

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 »