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 »

Zopotantor: Feb 24, 2013; ...und ist er drin dann lassen wir ihn niemals wieder raus...

LOOK I AM A TURTLE posted:

I actually generally prefer �P ∨ �Q to �(P ∧ Q), because my desire to have as few parentheses as possible trumps my desire to have as few negations as possible. In the first example it's easier to see at a glance that P = F implies that the whole expression is true, which is important sometimes. The second example technically also has one more token in it than the first one, so while you and others may find it clearer, it's hard to argue that it's simpler. But I view all this as mostly a matter of personal taste, so I probably wouldn't tell anyone to change it one way or the other in a code review.

With �(P ∧ Q) you can swap the then/else branches and get rid of both the negation and the parentheses. In general, non-inverted conditions are easier to understand.

# ? Oct 14, 2017 15:12

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 12:56

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

Zopotantor posted:

With �(P ∧ Q) you can swap the then/else branches and get rid of both the negation and the parentheses. In general, non-inverted conditions are easier to understand.

If you have both a then and an else then yes, I agree. I always change if (!x) { a(); } else { b(); } to if (x) { b(); } else { a(); } if I have the opportunity.

# ? Oct 14, 2017 19:50

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

My logic with that particular example is more if either object or needed member are invalid or don't exist, stop execution of function

I guess you could do if they exist proceed but I find the nested ifs can become unmanageable

E: Or I could do if they both don't exist (i.e. !(x && x.y)) stop execution, and you could argue that is clearer? But then we're into preferences, and literally nowhere else in our system is it laid out like that. Also, you get into the problem of JavaScript needing to evaluate both and you get an error on x.y if x is null/undefined. But JavaScript is a horror unto itself with regard to these things.

Joda fucked around with this message at 15:40 on Oct 15, 2017

# ? Oct 14, 2017 20:54

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

Joda posted:

My logic with that particular example is more if either object or needed member are invalid or don't exist, stop execution of function

I guess you could do if they exist proceed but I find the nested ifs can become unmanageable

I agree and prefer to write it like that.

code:

function {
	if (bad thing) return
	if (other bad thing) return

	the function actually happens now
	return
}

feels a lot easier to write and read to me than

code:

function {
	if (good thing) {
		if (other good thing) {
			the logic happens here at this level of indentation
			Also if I add another check, all of the lines of the function will be counted as changed
		}
	}
	return
}

# ? Oct 15, 2017 01:19

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Swift's guard is (I think) intended for exactly that purpose and I love it.

# ? Oct 15, 2017 01:24

Tad Naff: Jul 8, 2004; _{I told you you'd be sorry buying an emoticon, but no, you were hung over. Well look at you now. It's not catching on at all!}

There should be 'iftrue', 'iffalse' built in to all languages. Remove 'if' since it causes problems with de Morgan and kids/managers not understanding. For Perl we can retain 'unless', but also introduce 'but'

# ? Oct 15, 2017 01:33

PhantomOfTheCopier: Aug 13, 2008; Pikabooze!

Code that doesn't fail out fast is a horror. If you see nested-good-ifs instead of the return/next/continue/skip idiom, complain about arrow code in the review. If you ever see 'unless' used in Ruby/Perl with a complex conditional, complain because it's probably confusing. If it's not in a single line, it's probably too confusing.

I once even saw someone post code with 'unless not thingy or something'. :/

# ? Oct 15, 2017 15:09

return0: Apr 11, 2007

LOOK I AM A TURTLE posted:

This is where someone should step in with a Fermi estimate of how many nearly meaningless bytes URG bytes have been sent over the wire since TCP was invented.

I reckon a few hard drives full.

# ? Oct 15, 2017 23:07

Dylan16807: May 12, 2010

return0 posted:

I reckon a few hard drives full.

Going by https://en.wikipedia.org/wiki/Internet_traffic and an average packet size around 500 bytes it's something like 20-30 exabytes.

More than a week or two of global hard drive production.

# ? Oct 16, 2017 01:07

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

pokeyman posted:

Swift's guard is (I think) intended for exactly that purpose and I love it.

Yep.

# ? Oct 16, 2017 03:48

Xik: Mar 10, 2011; Dinosaur Gum

quote:

Hi [Dev Team]

If you have spare capacity, it would be good to go back through some our legacy solutions and make sure they have at least 80% unit test coverage, preferably 100%...

Sincerely,
Your now least favorite person in the team

I open one of the solutions:
Single monolithic project. No unit tests. No dependency injection. Handful of anti-patterns I've only ever seen as counter-examples in a programming patterns book.

:emo:

# ? Oct 16, 2017 07:51

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Xik posted:

I open one of the solutions:
Single monolithic project. No unit tests. No dependency injection. Handful of anti-patterns I've only ever seen as counter-examples in a programming patterns book.

Just game the code coverage number. Write a bunch of useless tests that inflate the number. And then explain that arbitrary code coverage % requirements are dumb and that code coverage is meaningless on its own -- all it can reliably tell you is what code doesn't have any tests attempting to test it.

# ? Oct 16, 2017 13:38

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

New Yorp New Yorp posted:

Just game the code coverage number. Write a bunch of useless tests that inflate the number. And then explain that arbitrary code coverage % requirements are dumb and that code coverage is meaningless on its own -- all it can reliably tell you is what code doesn't have any tests attempting to test it.

The first requirements are naive by design. Then the project manager writes better requirements and you'll have to write better tests to satisfy those reqs, rinse and repeat. Req-Driven Testing.

# ? Oct 16, 2017 13:48

TheresaJayne: Jul 1, 2011

Xik posted:

I open one of the solutions:
Single monolithic project. No unit tests. No dependency injection. Handful of anti-patterns I've only ever seen as counter-examples in a programming patterns book.

one of the projects i used to work on they wanted min 80% coverage and 100% on all new code,

It meant we had to unit Test All Enums until i realised that if you check the parent enum,SOMEENUM.value()l it would complete all 100%

# ? Oct 16, 2017 13:53

Pollyanna: Mar 5, 2005; Milk's on them.

https://twitter.com/internetofshit/status/919870551002353664

TheresaJayne posted:

one of the projects i used to work on they wanted min 80% coverage and 100% on all new code,

It meant we had to unit Test All Enums until i realised that if you check the parent enum,SOMEENUM.value()l it would complete all 100%

The problem with code coverage is that it approaches 100% whether or not you test for correctness instead of existence. It is useless on its own. As such, I love the idea of just bullshitting the whole thing. :shepface:

# ? Oct 16, 2017 14:55

Rubellavator: Aug 16, 2007

A former coworker got grilled by his new team for taking too long to write unit tests. Turns out he was writing real tests that actually tested things, all they wanted was code coverage for contract compliance. So they actually had him go back and remove all the asserts in his tests.

Now he's writing documentation, can't wait to see how they get mad at him for doing reasonable normal things.

Rubellavator fucked around with this message at 15:47 on Oct 16, 2017

# ? Oct 16, 2017 15:44

Eleeleth: Jun 21, 2009; Damn, that is one suave eel.

Rubellavator posted:

So they actually had him go back and remove all the asserts in his tests.

w-what?

# ? Oct 16, 2017 16:37

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Tomie knows me posted:

w-what?

Tests with no assertions are great, they never fail. Unless the code starts throwing unhandled exceptions, of course. But then you can just comment out the test logic and put "Assert.IsTrue(true)" in there and everything's cool again.

# ? Oct 16, 2017 16:59

necrotic: Aug 2, 2005; I owe my brother big time for this!

Nah you wrap it all in try/catch so the coverage doesn't go dwon

# ? Oct 16, 2017 17:36

Jeb Bush 2012: Apr 4, 2007; A mathematician, like a painter or poet, is a maker of patterns. If his patterns are more permanent than theirs, it is because they are made with ideas.

necrotic posted:

Nah you wrap it all in try/catch so the coverage doesn't go dwon

wouldn't that lose code coverage after the point where the exception happens? (assuming the try-catch block is in the test, since adding it into the code seems dangerously close to actually finding and fixing bugs)

# ? Oct 16, 2017 17:41

necrotic: Aug 2, 2005; I owe my brother big time for this!

Replacing the entire test with assert.ok removes even more coverage

# ? Oct 16, 2017 20:06

Rubellavator: Aug 16, 2007

We joked about autogenerating a class that is x times larger than the codebase that just counts to a million or something with a single test to cover it.

# ? Oct 16, 2017 20:29

CPColin: Sep 9, 2003; Big ol' smile.

This is weird, right? It's not just because I don't know C# very well?

C# code:

        #region date check
        public static bool IsValidDate(DateTime? dateObject)
        {
            if ((dateObject.HasValue) && (IsValidDate(dateObject.Value)))
                return true;

            return false;
        }

        public static bool IsValidDate(DateTime dateObject)
        {
            try
            {
                if ((dateObject != null) && (dateObject != DateTime.MinValue) && (dateObject != DateTime.MaxValue) && (dateObject > Convert.ToDateTime("1/1/1900")))
                    return true;

                return false;
            }
            catch
            {
                throw;
            }
        }
        #endregion

# ? Oct 16, 2017 21:31

Linear Zoetrope: Nov 28, 2011; A hero must cook

If I had to guess, the

code:

catch {
    throw;
}

Is meant to obliterate largely meaningless stack trace information from sections of code out of your own control? I have no idea if it's a common pattern though, I don't use C#.

# ? Oct 16, 2017 21:40

dwazegek: Feb 11, 2005; WE CAN USE THIS

CPColin posted:

This is weird, right? It's not just because I don't know C# very well?

It has a bunch of unnecessary checks, as well as a possible localization bug. So, yeah, it's definitely not great.

Why 1 jan 1900 wouldn't be valid, but a few nanoseconds later would be is also strange.

A more succinct way would be

code:


public static void IsValidDate(DateTime? date) 
{
    return date > new DateTime(1900, 1, 1) && date != DateTime.MaxValue;
}

# ? Oct 16, 2017 21:45

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Linear Zoetrope posted:

If I had to guess, the
code:
catch {
    throw;
}
Is meant to obliterate largely meaningless stack trace information from sections of code out of your own control? I have no idea if it's a common pattern though, I don't use C#.

Nope. catch { throw; } is exactly the same as not catching an exception at all. It's useless.

throw ex would dump the stack trace.

# ? Oct 16, 2017 21:49

dwazegek: Feb 11, 2005; WE CAN USE THIS

Linear Zoetrope posted:

If I had to guess, the
code:
catch {
    throw;
}
Is meant to obliterate largely meaningless stack trace information from sections of code out of your own control? I have no idea if it's a common pattern though, I don't use C#.

No, then you'd have to do

code:

catch(Exception ex) {
    throw ex;
}

A bare throw is only valid in a catch scope, and rethrows while maintaining the stacktrace.

The catch/rethrow here is most likely to have a place to attch a debugger.

# ? Oct 16, 2017 21:49

Pollyanna: Mar 5, 2005; Milk's on them.

So, sloppy code.

# ? Oct 16, 2017 22:56

Coffee Mugshot: Jun 26, 2010; by Lowtax

I'd consider a c++ file littered with #ifndef for a debugger to be "battle tested" rather than sloppy code.

# ? Oct 16, 2017 23:00

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

100% coverage seems like 100% availability: possible but not worth the cost for any system above a certain size.

# ? Oct 16, 2017 23:06

Coffee Mugshot: Jun 26, 2010; by Lowtax

You're saying we should be targeting four 9s in our code coverage, right?

# ? Oct 16, 2017 23:50

JawnV6: Jul 4, 2004; So hot ...

It's the inverse of a "speed-up loop"

code:

// add 0's for coverage
for(i=0;i<1000000;i++) {;}

# ? Oct 17, 2017 00:24

iospace: Jan 19, 2038

JawnV6 posted:

It's the inverse of a "speed-up loop"
code:
// add 0's for coverage
for(i=0;i<1000000;i++) {;}

Ok, I shouldn't talk because I'm abusing a function to delay a set number of ms, but that's also with a fixed clock frequency.

# ? Oct 17, 2017 00:28

redleader: Aug 18, 2005; Engage according to operational parameters

dwazegek posted:

Why 1 jan 1900 wouldn't be valid, but a few nanoseconds later would be is also strange.

Sounds like a sentinel value of some sort.

# ? Oct 17, 2017 06:15

Corla Plankun: May 8, 2007; improve the lives of everyone

January 1st, 1900 is the "epoch"-like zero-point that MS Office uses instead of 1970.

# ? Oct 17, 2017 12:36

fishmech: Jul 16, 2006; by VideoGames; Salad Prong

Corla Plankun posted:

January 1st, 1900 is the "epoch"-like zero-point that MS Office uses instead of 1970.

Microsoft Excel uses "January 0, 1900", which is supposed to be December 31, 1899 (using a convention developed for astronomical observances) and the calendar for 1900 includes February 29 which didn't occur that year. Both of these are to simplify interoperation with old Lotus 1-2-3 spreadsheets, as the developers of that made the original mistake.

The net result is the earliest date you can store in Excel is actually December 30, 1899 and that the first date you can store that's actually correct is March 1, 1900. And the same epoch is meant to be used in all Office applications, and gets used elsewhere in Windows some times.

A variant of this where 1900 isn't incorrectly recorded as a leap year, and so the calculations aren't off by one for very old dates, is I think in use in VBA within office.

# ? Oct 17, 2017 14:18

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

Doesn't .xls have a flag that tells you whether dates are counting from 1900 or 1901 for compatibility with Mac dates or something like that?

# ? Oct 17, 2017 16:57

biznatchio: Mar 31, 2001; Buglord

New Yorp New Yorp posted:

Nope. catch { throw; } is exactly the same as not catching an exception at all. It's useless.

That's not true, actually. throw; alters the line number in the stack trace for the method containing the throw; statement to point to the line of the rethrow rather than the line in that method where the exception originally occurred.

That makes catch { throw; } strictly worse than not having a try/catch at all (if the performance waste isn't already enough). Plus, the stack trace changing behavior masking the true exception source is annoying as poo poo in cases where you actually want to do real error handling before rethrowing an exception.

biznatchio fucked around with this message at 17:10 on Oct 17, 2017

# ? Oct 17, 2017 17:07

dwazegek: Feb 11, 2005; WE CAN USE THIS

biznatchio posted:

Plus, the stack trace changing behavior masking the true exception source is annoying as poo poo in cases where you actually want to do real error handling before rethrowing an exception.

You could do this

code:


catch (Exception ex) when (Handle(ex))
{
    throw; // this line never gets executed
}

bool Handle(Exception ex) 
{
    //handling goes here
    return false;
}

Yes, it's really ugly, but afaik it shouldn't mess up the line numbers.

# ? Oct 17, 2017 17:28

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 12:56

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

Python code:

DOES_NOT_EXIST_VALUE = "DNE"
NULL_VALUE = "NULL"
EV2 = "ev2"
EV3 = "ev3"

# ? Oct 18, 2017 04:23

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 »