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!

«‹›1501 »

xtal: Jan 9, 2011; by Fluffdaddy

I would rather my shell's source code came with a picture of Guy Fieri than that

# ? Nov 30, 2016 03:34

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 06:33

Absurd Alhazred: Mar 27, 2010; by Athanatos

Fergus Mac Roich posted:

http://research.swtch.com/shmacro

Reminds me of this little gem, one of the winnners of the 2000 International Obfuscated C Code Contest
.

# ? Nov 30, 2016 03:57

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

My recent favorite for this is the mintty source code which has:

C++ code:

  switch (width) {
    when 1:  // Normal character.
      term_check_boundary(curs->x, curs->y);
      term_check_boundary(curs->x + 1, curs->y);
      put_char(c);
    when 2 or 3: // Double-width char (Triple-width was an experimental option).

https://github.com/mintty/mintty/blob/master/src/std.h#L124-L126

# ? Nov 30, 2016 04:53

VikingofRock: Aug 24, 2008

Suspicious Dish posted:

My recent favorite for this is the mintty source code which has:
C++ code:
  switch (width) {
    when 1:  // Normal character.
      term_check_boundary(curs->x, curs->y);
      term_check_boundary(curs->x + 1, curs->y);
      put_char(c);
    when 2 or 3: // Double-width char (Triple-width was an experimental option).
https://github.com/mintty/mintty/blob/master/src/std.h#L124-L126

For posterity, the link to the current version of that file is https://github.com/mintty/mintty/blob/2e4e620b86a69dadfe1ca1e8f34b421c7e89ec53/src/std.h#L124-L126.

Also that's equal parts ingenious and horrifying. I'm not really sure why you would do that.

# ? Nov 30, 2016 05:04

Fergus Mac Roich: Nov 5, 2008; Soiled Meat

I wonder if anyone does horrible things with the C Preprocessor while writing in languages that aren't C, as in running a non-C source code file through gcc -E as part of a compilation step.

# ? Nov 30, 2016 05:13

brap: Aug 23, 2004; Grimey Drawer

hosed up things are basically all #define enables you to do. Look at the Linux kernel. It's the ability to define your own syntax sugar that resists tooling and validation of what the code is actually doing.

# ? Nov 30, 2016 05:48

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

Fergus Mac Roich posted:

I wonder if anyone does horrible things with the C Preprocessor while writing in languages that aren't C, as in running a non-C source code file through gcc -E as part of a compilation step.

I once built a static HTML site using the preprocessor. I was crunched for time and didn't have time to learn something like Jekyll.

# ? Nov 30, 2016 06:22

Master_Odin: Apr 15, 2010; My spear never misses its mark...

ladies

Fergus Mac Roich posted:

I wonder if anyone does horrible things with the C Preprocessor while writing in languages that aren't C, as in running a non-C source code file through gcc -E as part of a compilation step.

I've been part of a project that used it to parse out C style comments from a JSON file because by golly, we need comments in those json files and we cannot just have a dummy field called _comment!

# ? Nov 30, 2016 07:15

xtal: Jan 9, 2011; by Fluffdaddy

Fergus Mac Roich posted:

I wonder if anyone does horrible things with the C Preprocessor while writing in languages that aren't C, as in running a non-C source code file through gcc -E as part of a compilation step.

Haskell uses CPP

# ? Nov 30, 2016 12:42

Bonfire Lit: Jul 9, 2008; If you're one of the sinners who caused this please unfriend me now.

Fergus Mac Roich posted:

I wonder if anyone does horrible things with the C Preprocessor while writing in languages that aren't C, as in running a non-C source code file through gcc -E as part of a compilation step.

The GTK stack uses the C preprocessor to generate MSBuild projects (which are XML files).

# ? Nov 30, 2016 13:07

dougdrums: Feb 25, 2005; CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)

I once made a joke about writing an interpreter for a simple functional language entirely in C macros, which happened to taken seriously ...

I got the idea from reading http://conal.net/blog/posts/the-c-language-is-purely-functional

I'm sure there's a couple on github now ...

# ? Nov 30, 2016 14:29

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

Made the mistake once again (I should know better) of Googling "Oracle alter table". One of the top results is a page hosted on oracle.com that actually relates to "JavaDB", which I've never heard of before today but is obviously some other thing Oracle does. Of course there is no obvious indication on the page what product it relates to, or at least none that you'd detect if you are just skimming the information. I should know better because I've been bitten by this in the past when searches containing "oracle" came up with pages they were hosting that were actually about MySQL. Oracle's website is clearly considered a high-quality search result by Google, despite the fact that they don't take the time to make it clear which product their high-scoring web pages relate to...

# ? Nov 30, 2016 14:58

FlapYoJacks: Feb 12, 2009

fleshweasel posted:

hosed up things are basically all #define enables you to do. Look at the Linux kernel. It's the ability to define your own syntax sugar that resists tooling and validation of what the code is actually doing.

As a kernel dev; can confirm. Although it's getting better, the true horrors are all from embedded manufactures. Freescale (now NXP [now Qualcomm]) in their 3.0.35 kernel for the imx6 processors had up to 3 layers worth of macros for some of their pad initialization code. poo poo was a absolute nightmare to dig through.

# ? Nov 30, 2016 15:55

dougdrums: Feb 25, 2005; CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)

Doesn't Torvalds work for ~~freescale~~?

e: I got freescale confused with transmeta somehow ...

... and according to http://www.linfo.org/linus.html he doesn't even work there anymore, and hasn't for awhile ...

dougdrums fucked around with this message at 18:17 on Nov 30, 2016

# ? Nov 30, 2016 18:12

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

dougdrums posted:

e: I got freescale confused with transmeta somehow ...

Nobody's worked for Transmeta since 2009

# ? Nov 30, 2016 18:32

canis minor: May 4, 2011

i'm two versions of assert-plus and three versions of async, only on this screen. the entire list is much much longer. node.js, never change and just kill me now

# ? Nov 30, 2016 19:03

Spatial: Nov 15, 2007

C macros are a local minima. Just enough functionality to never bother improving anything.

# ? Nov 30, 2016 22:12

Master_Odin: Apr 15, 2010; My spear never misses its mark...

ladies

canis minor posted:

i'm two versions of assert-plus and three versions of async, only on this screen. the entire list is much much longer. node.js, never change and just kill me now

This is more on libraries using outdated dependencies that they'll never update but nobody will notice until the library completely stops working and turns out it hasn't had a commit in 2 years.

# ? Nov 30, 2016 22:47

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

Spatial posted:

C macros are a local minima. Just enough functionality to never bother improving anything.

For some reason I thought K&R didn't have a preprocessor but I looked it up and although it wasn't part of the earliest version of NB/C but it appeared shortly thereafter. Apparently the original implementation didn't even invoke the preprocessor unless you had a "special signal" at the beginning of the source file and half of what it does was just accidental implementation details and quirks of various compiler vendors. Ritchie cites this as one of the reasons it fits so poorly with the overall language - half of them weren't even using it.

# ? Dec 1, 2016 08:51

Crumpet: Apr 22, 2008

All semblance of good coding practice seems to disappear when the developers here are asked to write unit tests. I'm also pretty sure that none of the devs here actually know what a unit test is, since the 'unit' tests that have been produced do no mocking at all, and require databases to be configured so that almost completely useless tests like this can be run (I've obviously modified some of the variable/method names to remove company info):

code:

@Test
public void verifyCountries() {
    List<Country> countries = TEST_COUNTRIES;
    assertTrue(countries.size() > 0);
    for (Country country : countries) {
        System.out.println(JsonUtils.toJson(country));
        assertNotNull(country.getId());
        assertNotNull(country.getName());
    }
}

TEST_COUNTRIES is a pre-populated list of country objects they created manually in a static initializer block. I really do not know why they wrote this. A lot of the other 'unit' tests love to query actual databases and check random, almost pointless criteria on the data returned.

They also love to copy & paste the same test many times, simply to change a single value:

code:

@Test
public void scheduleValidateSchedulesTestSchedule1() {
    Schedule schedule = getTestSchedule();
    schedule.setMondaySchedule("1");

    Response response = new Response();
    schedule.validate(response, true);
    assertFalse("incorrect fail parse", response.hasFailed());
}


@Test
public void scheduleValidateSchedulesTestSchedule2() {
    Schedule schedule = getTestSchedule();
    schedule.setMondaySchedule("0");

    Response response = new Response();
    schedule.validate(response, true);
    assertFalse("incorrect fail parse", response.hasFailed());
}

[snipping out tests 3 - 17, but they're exactly the same minus the single string value]

@Test
public void scheduleValidateSchedulesTestSchedule18() {
    Schedule schedule = getTestSchedule();
    schedule.setMondaySchedule("00:00-01:00|09:00-12:10|12:10-23:59");

    Response response = new Response();
    schedule.validate(response, true);
    assertFalse("incorrect fail parse", response.hasFailed());
}

There are so many occurrences of this sort of thing that I wonder if even half the tests in these projects are actually useful at all.

Surprisingly, the actual code for the projects themselves is fairly reasonable; I get that devs might not like to write tests, but it would be nice if they'd at least make an effort to write tests that look like they were written by a sane person (and actually do something worthwhile other than trick test coverage plugins).

# ? Dec 1, 2016 13:31

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

It just seems like the utility of unit tests is lost on a lot of developers. I've seen a lot of the same things on my current project and previous ones. What I think it comes down to is just a fundamental misunderstanding of the purpose and goal of unit testing. I joined my most recent project and walked into a pile of 'every class is interfaced, and huge swaths of our unit tests were just mocks that implemented those interfaces, with methods being copy-pasted from the real code and *slightly* altered to allow them to run under test circumstances.

I've had some luck in trying to explain unit testing as a matter of branch-exploration: When a method contains an if(), then you're going to need to write a test that dodges that and one that hits it. But in general it just seems to require some fundamental eureka moment that a lot of folks just get to in their own time.

# ? Dec 1, 2016 15:05

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

Unit tests seemed useless to me until I wanted to rework some implementation details and realized I could do so without unknowingly screwing everyone over.

If you never (or only superficially) need to maintain the code, I can understand never seeing the value.

# ? Dec 1, 2016 15:35

Crumpet: Apr 22, 2008

pokeyman posted:

If you never (or only superficially) need to maintain the code, I can understand never seeing the value.

This code is changed on a weekly basis according to the git commit history.

# ? Dec 1, 2016 15:40

5TonsOfFlax: Aug 31, 2001

I'll speak for the unpopular opinion: Writing unit tests ahead of time IS useless. You can only write tests for what you can foresee going wrong, and you're going to test that manually during development anyway.

Writing _testable_ code is important, because it correlates well with good architecture practices. And writing tests for issues that pop up after deployment is good, since that's something that you didn't foresee and is probably a corner case that's easy to overlook and therefore might break again on refactor.

Testing for testing's sake is stupid. The point of the code is to accomplish something, not to have a badge that says that it passes some test suite.

# ? Dec 1, 2016 16:05

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Cuntpunch posted:

I've had some luck in trying to explain unit testing as a matter of branch-exploration: When a method contains an if(), then you're going to need to write a test that dodges that and one that hits it. But in general it just seems to require some fundamental eureka moment that a lot of folks just get to in their own time.

This seems... wrong to me. Sounds like you're testing the specific implementation of the method. What if the implementation changes, are you supposed to rewrite all the tests?

# ? Dec 1, 2016 16:12

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

5TonsOfFlax posted:

I'll speak for the unpopular opinion: Writing unit tests ahead of time IS useless. You can only write tests for what you can foresee going wrong, and you're going to test that manually during development anyway.

Writing _testable_ code is important, because it correlates well with good architecture practices. And writing tests for issues that pop up after deployment is good, since that's something that you didn't foresee and is probably a corner case that's easy to overlook and therefore might break again on refactor.

Testing for testing's sake is stupid. The point of the code is to accomplish something, not to have a badge that says that it passes some test suite.

i agree regression tests are good

# ? Dec 1, 2016 16:17

Space Kablooey: May 6, 2009

Yeah but writing tests first and then writing or changing code and the tests pass gives me a good high

# ? Dec 1, 2016 16:41

fritz: Jul 26, 2003

HappyHippo posted:

This seems... wrong to me. Sounds like you're testing the specific implementation of the method. What if the implementation changes, are you supposed to rewrite all the tests?

If you have a test for 'this one weird edge case' that comes up in a particular implementation, and then the implementation changes, that test should still be perfectly valid, just not necessarily interesting anymore.

# ? Dec 1, 2016 16:45

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

5TonsOfFlax posted:

I'll speak for the unpopular opinion: Writing unit tests ahead of time IS useless. You can only write tests for what you can foresee going wrong, and you're going to test that manually during development anyway.

Writing _testable_ code is important, because it correlates well with good architecture practices. And writing tests for issues that pop up after deployment is good, since that's something that you didn't foresee and is probably a corner case that's easy to overlook and therefore might break again on refactor.

You're missing the part where I can make changes to the code, and then instead of manually testing the code, I can just punch in the unit test, and fifteen seconds later I'll know down to the function level where I broke it. Sure I could have discovered that by manually running a regression suite, discovering the results didn't match what I wanted, and doing the whole debugging process until I figure out what went wrong...but that takes a lot longer.

With a little practice, it doesn't take much time to write the tests, and they save so much time in the form of developer testing that realistically they'll have paid themselves back inside of a month at worst.

Stealth edit: of course that doesn't excuse you from having integration tests, but considering how much of developer time is spent on fixing broken code, anything you can do to speed that process up is a good thing.

# ? Dec 1, 2016 16:55

FlapYoJacks: Feb 12, 2009

Guys guys guys guys.

Maybe we could have unit tests AND regression tests?

# ? Dec 1, 2016 17:01

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

ratbert90 posted:

Guys guys guys guys.

Maybe we could have unit tests AND regression tests?

BUT THERE'S NO TIME TO WRITE TESTS!!!

# ? Dec 1, 2016 17:13

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

I saw, during a code review, a bit of code that relied on another bit of code outputting an exact sequence of characters. I asked my coworker to write a unit test that verified the functionality, in case we ever rewrite the code to output a slightly different sequence of characters. What I really wanted to ask was, "How come you didn't write that unit test already?"

Then the coworker asked where to put it, how to run unit tests, etc.

# ? Dec 1, 2016 17:51

taqueso: Mar 8, 2004

CPColin posted:

I saw, during a code review, a bit of code that relied on another bit of code outputting an exact sequence of characters. I asked my coworker to write a unit test that verified the functionality, in case we ever rewrite the code to output a slightly different sequence of characters. What I really wanted to ask was, "How come you didn't write that unit test already?"

Then the coworker asked where to put it, how to run unit tests, etc.

Really, that's awesome and you should be happy to help someone learn. It was well after I was out of college when I had finally been burned enough by not having testing that I 'got' unit tests and why it was worth spending the energy. I wish I someone had mentored me on it earlier.

The question is, though, did it stick?

# ? Dec 1, 2016 18:07

qntm: Jun 17, 2009

HappyHippo posted:

This seems... wrong to me. Sounds like you're testing the specific implementation of the method. What if the implementation changes, are you supposed to rewrite all the tests?

Sure. Unit tests are white-box (well, transparent-box), implementation-aware tests. I would also accept leaving all the existing tests (which should continue to pass under the new implementation) in place and writing additional ones to cover the new implementation.

# ? Dec 1, 2016 18:49

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

taqueso posted:

Really, that's awesome and you should be happy to help someone learn. It was well after I was out of college when I had finally been burned enough by not having testing that I 'got' unit tests and why it was worth spending the energy. I wish I someone had mentored me on it earlier.

The question is, though, did it stick?

It clearly didn't stick the last handful of times I recommended during team meetings that we should all be writing more unit tests (and said coworker was nodding along).

# ? Dec 1, 2016 19:13

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

HappyHippo posted:

This seems... wrong to me. Sounds like you're testing the specific implementation of the method. What if the implementation changes, are you supposed to rewrite all the tests?

I'm thinking about it from a "write unit tests after the fact" sense. If you're TDD'ing this probably doesn't quite apply. But the logic behind it seems sound. Consider:

code:


public int AbsoluteValue(int x)
{
	if(x < 0) return x * -1;
	
	return x;
}

Is how I imagine most people would throw together a quick manual Abs method. It's quick and dirty and obvious. But the very way we code that points out the way to testing it: We have two branches, one for x<0, one for x>=0. So we write tests to reinforce known good values for both of those possible input/output pairs. At that point some clever person can come in and refactor this to use bitmath or other voodoo, but the tests will still be supporting the logical requirements of the method.

But imagine the usual massive methods with cyclomatic complexity in the double(or, god forbid, triple) digits. What I tend to see is people who write these monstrosities to 'just work', and then they only end up bothering to write a unit test or two around a 'happy path' through the code, leaving coverage at a sad state.

# ? Dec 1, 2016 21:05

jony neuemonic: Nov 13, 2009

TooMuchAbstraction posted:

You're missing the part where I can make changes to the code, and then instead of manually testing the code, I can just punch in the unit test, and fifteen seconds later I'll know down to the function level where I broke it. Sure I could have discovered that by manually running a regression suite, discovering the results didn't match what I wanted, and doing the whole debugging process until I figure out what went wrong...but that takes a lot longer.

With a little practice, it doesn't take much time to write the tests, and they save so much time in the form of developer testing that realistically they'll have paid themselves back inside of a month at worst.

Stealth edit: of course that doesn't excuse you from having integration tests, but considering how much of developer time is spent on fixing broken code, anything you can do to speed that process up is a good thing.

They also force you to eat your own dog food, which is never a bad thing.

# ? Dec 1, 2016 21:11

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Cuntpunch posted:

I'm thinking about it from a "write unit tests after the fact" sense. If you're TDD'ing this probably doesn't quite apply. But the logic behind it seems sound. Consider:
code:
public int AbsoluteValue(int x)
{
	if(x < 0) return x * -1;
	
	return x;
}
Is how I imagine most people would throw together a quick manual Abs method. It's quick and dirty and obvious. But the very way we code that points out the way to testing it: We have two branches, one for x<0, one for x>=0. So we write tests to reinforce known good values for both of those possible input/output pairs. At that point some clever person can come in and refactor this to use bitmath or other voodoo, but the tests will still be supporting the logical requirements of the method.

But imagine the usual massive methods with cyclomatic complexity in the double(or, god forbid, triple) digits. What I tend to see is people who write these monstrosities to 'just work', and then they only end up bothering to write a unit test or two around a 'happy path' through the code, leaving coverage at a sad state.

Yeah if you mean it more as inspiration for test cases that makes sense (although if I asked you to test an abs function without showing you the code you'd likely come up with the same test cases), and you make a good point about not just testing the "happy path".

# ? Dec 1, 2016 21:37

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

Unit tests should test behaviors that your code relies upon being consistent. While unit tests != regression tests, the way that unit tests are oftentimes implemented overlaps heavily with the needs of regression tests. If your test structures and validity depend unintentionally upon changes in implementation of a code path this doesn't invalidate your tests. If your code guarantees that you will only call a function within an integer range and the function you depend upon supports a lot more, you don't need to cover more than you're using.... until you decide to increase the integer range support. That wouldn't be a regression in behavior as much as catching inputs (or sometimes states) that cause unanticipated behavior.

In my experience I see bigger problems with confusing integration and unit tests. If your tests depend upon a database existing and it's supposed to run constantly, it probably shouldn't belong in a unit test.

# ? Dec 1, 2016 22:54

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 06:33

qntm: Jun 17, 2009

Okay, I need to step back for a second. Isn't every test a regression test? Under normal circumstances, every test should pass, and if a test fails, there's been a regression, right?

# ? Dec 1, 2016 23:41

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!

«‹›1501 »