Back in July, I wrote about my disdain for ternary operators citing a monster representative line as being a great example of an attempt at cleverness gone too far.
Well, an anonymous submitter sent our way another ternary operator disaster but with a twist - nested within the call to "payRecordsList.Add", almost every parameter passed has its own ternary operator added.
payRecordsList.Add(payRecord.DateLeft == null ? includePayrollIDinResult == false ? string.Format("{0:dd/MM/yyyy} to Present : {1} ({2})", payRecord.DateStarted, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) : string.Format("{0:dd/MM/yyyy} to Present : {1} ({2})", payRecord.DateStarted, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) + "|" + payRecord.Department.PayrollCompanyID : includePayrollIDinResult == false ? string.Format("{0:dd/MM/yyyy} to {1:dd/MM/yyyy} : {2} ({3})", payRecord.DateStarted, payRecord.DateLeft, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) : string.Format("{0:dd/MM/yyyy} to {1:dd/MM/yyyy} : {2} ({3})", payRecord.DateStarted, payRecord.DateLeft, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) + "|" + payRecord.Department.PayrollCompanyID, payRecord.ID);
You know, I have to hand it to the developer responsible - this is quite a feat of complex software engineering. However, if you figure that this representative line is only one of many similar function calls in the application, then well, let's just say I hope that the code never breaks. Or needs updated. Forever.