Can you top that?
-
My rule of thumb is "4 method parameters are fine, 6 is questionable, 8 are a problem". Here I present you what I have to deal with:
long BunnyInitSub( BunnyType eBunnyType,
long lBunnyIndex,
CString sBunnyLabel1,
long lBunnyColor1,
bool bBunnyAutoScale1,
bool bBunnyAutoMin1,
bool bBunnyAutoMax1,
double dBunnyMin1,
double dBunnyMax1,
bool bBunnyLogScale1,
bool bOverlap,
long lBunnyPlotFirst,
bool bEnableSecondPlot,
long lBunnyPlotSecond = EASTER_LINE,
bool bEnableSubBunny = false,
CString sBunnyLabel2 = _T(""),
long lBunnyColor2 = black,
bool bBunnyAutoScale2 = true,
bool bBunnyAutoMin2 = true,
bool bBunnyAutoMax2 = true,
double dBunnyMin2 = 0,
double dBunnyMax2 = 0,
bool bBunnyLogScale2 = false );Thank you, Visual Assist, for coping with this horror! (No it's not
Bunnyin the original code. Changed to protect the nocent.) Yes, this is more or less two times the same information. Which are, internally, stored in a struct with similar layout as the method. Serialized raw, requiring two-way-compatibility. Which, due to some mishap with "storage size optimizations" don't even have identical alignment, so can't be replaced with two instances of half the struct. Gaaaaaaah!FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
My rule of thumb is "4 method parameters are fine, 6 is questionable, 8 are a problem". Here I present you what I have to deal with:
long BunnyInitSub( BunnyType eBunnyType,
long lBunnyIndex,
CString sBunnyLabel1,
long lBunnyColor1,
bool bBunnyAutoScale1,
bool bBunnyAutoMin1,
bool bBunnyAutoMax1,
double dBunnyMin1,
double dBunnyMax1,
bool bBunnyLogScale1,
bool bOverlap,
long lBunnyPlotFirst,
bool bEnableSecondPlot,
long lBunnyPlotSecond = EASTER_LINE,
bool bEnableSubBunny = false,
CString sBunnyLabel2 = _T(""),
long lBunnyColor2 = black,
bool bBunnyAutoScale2 = true,
bool bBunnyAutoMin2 = true,
bool bBunnyAutoMax2 = true,
double dBunnyMin2 = 0,
double dBunnyMax2 = 0,
bool bBunnyLogScale2 = false );Thank you, Visual Assist, for coping with this horror! (No it's not
Bunnyin the original code. Changed to protect the nocent.) Yes, this is more or less two times the same information. Which are, internally, stored in a struct with similar layout as the method. Serialized raw, requiring two-way-compatibility. Which, due to some mishap with "storage size optimizations" don't even have identical alignment, so can't be replaced with two instances of half the struct. Gaaaaaaah!FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyDidn't you happen to work with Excel COM API? For example
Microsoft.Office.Interop.Excel.Dialog.Showhas 30 parameters. Cool, isn't it? They are optional of course, but in languages like C# before 4.0 you've got to specify them all:mad: -
My rule of thumb is "4 method parameters are fine, 6 is questionable, 8 are a problem". Here I present you what I have to deal with:
long BunnyInitSub( BunnyType eBunnyType,
long lBunnyIndex,
CString sBunnyLabel1,
long lBunnyColor1,
bool bBunnyAutoScale1,
bool bBunnyAutoMin1,
bool bBunnyAutoMax1,
double dBunnyMin1,
double dBunnyMax1,
bool bBunnyLogScale1,
bool bOverlap,
long lBunnyPlotFirst,
bool bEnableSecondPlot,
long lBunnyPlotSecond = EASTER_LINE,
bool bEnableSubBunny = false,
CString sBunnyLabel2 = _T(""),
long lBunnyColor2 = black,
bool bBunnyAutoScale2 = true,
bool bBunnyAutoMin2 = true,
bool bBunnyAutoMax2 = true,
double dBunnyMin2 = 0,
double dBunnyMax2 = 0,
bool bBunnyLogScale2 = false );Thank you, Visual Assist, for coping with this horror! (No it's not
Bunnyin the original code. Changed to protect the nocent.) Yes, this is more or less two times the same information. Which are, internally, stored in a struct with similar layout as the method. Serialized raw, requiring two-way-compatibility. Which, due to some mishap with "storage size optimizations" don't even have identical alignment, so can't be replaced with two instances of half the struct. Gaaaaaaah!FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchySomeone there has no fucking idea how to pass object, object reference or pointer to object as a function parameter.
There is only one Ashley Judd and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
Someone there has no fucking idea how to pass object, object reference or pointer to object as a function parameter.
There is only one Ashley Judd and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
That's what I wished for: one struct per "bunny" with good initializers, and an Init method taking one or two of them. The guy would have done better with some guidance. It's a rarely used part of the API - I've already fixed the more common parts. What hurts most is that even without those objects, he could have folded three of the bools into the two doubles. Twice.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
My rule of thumb is "4 method parameters are fine, 6 is questionable, 8 are a problem". Here I present you what I have to deal with:
long BunnyInitSub( BunnyType eBunnyType,
long lBunnyIndex,
CString sBunnyLabel1,
long lBunnyColor1,
bool bBunnyAutoScale1,
bool bBunnyAutoMin1,
bool bBunnyAutoMax1,
double dBunnyMin1,
double dBunnyMax1,
bool bBunnyLogScale1,
bool bOverlap,
long lBunnyPlotFirst,
bool bEnableSecondPlot,
long lBunnyPlotSecond = EASTER_LINE,
bool bEnableSubBunny = false,
CString sBunnyLabel2 = _T(""),
long lBunnyColor2 = black,
bool bBunnyAutoScale2 = true,
bool bBunnyAutoMin2 = true,
bool bBunnyAutoMax2 = true,
double dBunnyMin2 = 0,
double dBunnyMax2 = 0,
bool bBunnyLogScale2 = false );Thank you, Visual Assist, for coping with this horror! (No it's not
Bunnyin the original code. Changed to protect the nocent.) Yes, this is more or less two times the same information. Which are, internally, stored in a struct with similar layout as the method. Serialized raw, requiring two-way-compatibility. Which, due to some mishap with "storage size optimizations" don't even have identical alignment, so can't be replaced with two instances of half the struct. Gaaaaaaah!FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
My rule of thumb is "4 method parameters are fine, 6 is questionable, 8 are a problem". Here I present you what I have to deal with:
long BunnyInitSub( BunnyType eBunnyType,
long lBunnyIndex,
CString sBunnyLabel1,
long lBunnyColor1,
bool bBunnyAutoScale1,
bool bBunnyAutoMin1,
bool bBunnyAutoMax1,
double dBunnyMin1,
double dBunnyMax1,
bool bBunnyLogScale1,
bool bOverlap,
long lBunnyPlotFirst,
bool bEnableSecondPlot,
long lBunnyPlotSecond = EASTER_LINE,
bool bEnableSubBunny = false,
CString sBunnyLabel2 = _T(""),
long lBunnyColor2 = black,
bool bBunnyAutoScale2 = true,
bool bBunnyAutoMin2 = true,
bool bBunnyAutoMax2 = true,
double dBunnyMin2 = 0,
double dBunnyMax2 = 0,
bool bBunnyLogScale2 = false );Thank you, Visual Assist, for coping with this horror! (No it's not
Bunnyin the original code. Changed to protect the nocent.) Yes, this is more or less two times the same information. Which are, internally, stored in a struct with similar layout as the method. Serialized raw, requiring two-way-compatibility. Which, due to some mishap with "storage size optimizations" don't even have identical alignment, so can't be replaced with two instances of half the struct. Gaaaaaaah!FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyYou never worked in the kernel then... NTSTATUS ZwCreateFile( __out PHANDLE FileHandle, __in ACCESS_MASK DesiredAccess, __in POBJECT_ATTRIBUTES ObjectAttributes, __out PIO_STATUS_BLOCK IoStatusBlock, __in_opt PLARGE_INTEGER AllocationSize, __in ULONG FileAttributes, __in ULONG ShareAccess, __in ULONG CreateDisposition, __in ULONG CreateOptions, __in_opt PVOID EaBuffer, __in ULONG EaLength );
"It is a remarkable fact that despite the worldwide expenditure of perhaps US$50 billion since 1990, and the efforts of tens of thousands of scientists worldwide, no human climate signal has yet been detected that is distinct from natural variation." Bob Carter, Research Professor of Geology, James Cook University, Townsville
-
You never worked in the kernel then... NTSTATUS ZwCreateFile( __out PHANDLE FileHandle, __in ACCESS_MASK DesiredAccess, __in POBJECT_ATTRIBUTES ObjectAttributes, __out PIO_STATUS_BLOCK IoStatusBlock, __in_opt PLARGE_INTEGER AllocationSize, __in ULONG FileAttributes, __in ULONG ShareAccess, __in ULONG CreateDisposition, __in ULONG CreateOptions, __in_opt PVOID EaBuffer, __in ULONG EaLength );
"It is a remarkable fact that despite the worldwide expenditure of perhaps US$50 billion since 1990, and the efforts of tens of thousands of scientists worldwide, no human climate signal has yet been detected that is distinct from natural variation." Bob Carter, Research Professor of Geology, James Cook University, Townsville
Still 11 < 23 ;) Not much worse than Win32 CreateFile. My rules of thumb would get some leeway (say a +2..+4 modifier) for a C-StyleAPI, so the scratch by. Also, it's a rule for orientation - if one in 100 methods violates that, it's fine, if one in ten does, it's a problem.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
My rule of thumb is "4 method parameters are fine, 6 is questionable, 8 are a problem". Here I present you what I have to deal with:
long BunnyInitSub( BunnyType eBunnyType,
long lBunnyIndex,
CString sBunnyLabel1,
long lBunnyColor1,
bool bBunnyAutoScale1,
bool bBunnyAutoMin1,
bool bBunnyAutoMax1,
double dBunnyMin1,
double dBunnyMax1,
bool bBunnyLogScale1,
bool bOverlap,
long lBunnyPlotFirst,
bool bEnableSecondPlot,
long lBunnyPlotSecond = EASTER_LINE,
bool bEnableSubBunny = false,
CString sBunnyLabel2 = _T(""),
long lBunnyColor2 = black,
bool bBunnyAutoScale2 = true,
bool bBunnyAutoMin2 = true,
bool bBunnyAutoMax2 = true,
double dBunnyMin2 = 0,
double dBunnyMax2 = 0,
bool bBunnyLogScale2 = false );Thank you, Visual Assist, for coping with this horror! (No it's not
Bunnyin the original code. Changed to protect the nocent.) Yes, this is more or less two times the same information. Which are, internally, stored in a struct with similar layout as the method. Serialized raw, requiring two-way-compatibility. Which, due to some mishap with "storage size optimizations" don't even have identical alignment, so can't be replaced with two instances of half the struct. Gaaaaaaah!FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyTop that? Easily. Here is just one of endlessly many similar static methods in an application I just replaced (including comments and documentation):
public static int DoSomethingWithBunnies(int auswahl, string artnr, string artbez, string lnam,
string lnr, string lartnr, string wg, string mkenz, string ean,
string gab, bool ges, bool bug, bool bau, bool eks, int stanort,
string uid)
{
// You don't want to see what comes here
}Edit: It's not the number of parameters that's the problem here. Much worse that all methods are static, usually at least 1000 lines of the worst spaghetti code long and often redundant. There are at least two more versions of this particular method here with '2' and '3' added to the name with little to no apparent differences in the copied code. All without any comments except for those I added or any documentation.
"I have what could be described as the most wide-open sense of humor on the site, and if I don't think something is funny, then it really isn't." - JSOC, 2011 -----
"Friar Modest never was a prior" - Italian proverb