Build failure exposes WTF
-
Another development team at my company was working on a project and checked the presentation layer file in to source control, but forgot to check in the library/data layer file with the corresponding changes. Not a big deal, we all do it from time to time. What was shocking was the error message in the build log:
"C:\source\foo\bar\APage.aspx.cs (247): No overload for method 'SearchForFooRecords' takes '69' arguments"
SIXTY NINE FREAKING ARGUMENTS! What the hell were they thinking?!
-
@stannius said:
Another development team at my company was working on a project and checked the presentation layer file in to source control, but forgot to check in the library/data layer file with the corresponding changes. Not a big deal, we all do it from time to time. What was shocking was the error message in the build log:
"C:\source\foo\bar\APage.aspx.cs (247): No overload for method 'SearchForFooRecords' takes '69' arguments"
SIXTY NINE FREAKING ARGUMENTS! What the hell were they thinking?!
I would hope (pray) that this code was autogenerated. I've worked with database abstraction layers that simply (read: poorly) wrap the tables/fields, so there are c'tors or set methods that take in every single field as arguments. Even if that was the case, 69 fields in a table would be awful too.
-
"Well, they said I wasn't allowed to use global variables, so...."
-
If you search around some, there are library functions that take that many arguments or more.
I believe a recent example was a Microsoft-provided C# function for interacting with Excell spreadsheets.
-
69 arguments, dude!
This typically would generate the dreaded
<font face="Tahoma">
<font size="4">Error 420: File not found, man...</font>
I was, like, totally all about getting that file, dude, but then I remembered that I forgot to feed my cat, and by the time I had that done, there was this cool show on TV... eh... what were we talking about?</font>
