- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Further proof that we call them numbskulls because their skulls are numb, i.e. there is no nerve tissue inside them at all.
Admin
Admin
I remember trying to explain this exact same thing to a colleague once (well, the second part about how he'd set the destination to be equal to the source). After about 40 minutes my skull felt pretty numb.
Admin
The real wtf is why the parameters are named "src" and "desc".
Admin
Yea, I remember a similar case when I (in vain) tried to explain the difference between relative and absolute error. A guest postdoc wanted a gas flow of 2 % of the full scale of the controller with a absolute error of 1% full-scale and he couldn't understand why he didn't get what he specified: 'But the controller has a maximum error of 1%' he continued to say.... (hint in that case getting anything within 1 and 3% full-scale is within spec, which equates to 100% relative error) Yes it actually happened and he had a pHd (at least that was what the papers said)......
Admin
That might be the problem, of course. Is a pHd better or worse than a PhD?
Admin
In this cASE, um, possibly.
Admin
I can think of a lot of CaSEs where toggling cAseS might make things worse, and toggling them again make them even worse.
Admin
This seems like a pretty basic error, really.
Admin
Never having to deal with such a thing, what is it meant to look like? E.g. if src is null, set it from desc, else set desc from src?
Admin
I wish I had made that error on purpose, as you say a pretty basic error ;-)
Admin
Toggling cases is a capital error.
Admin
Maybe the real WTF is all the layers created by these tools supposedly making life easier. Added complexity is never better, IMHO.
Admin
Admin
They're the source and descination, of course ;)
Admin
Automapper really just helps to remove boilerplate and infer as much as it can without requiring lots of error prone manual coding. I agree that incorporating too much "magic" automation into a project makes it significantly harder to debug, especially in corner cases where the tool in question wasn't really designed to be used. It's all a matter of compromise and a good architect should understand this.
We have a C# project which HEAVILY utilizes PostSharp (an aspect oriented programming tool, which modifies CIL bytecode after compilation. Yes, it removes an awful lot of boilerplate (especially if you are unfortunate enough to still be working with WPF), but it can also be used to alter the basic semantics of the language in "clever" ways, which if you understand them (or know of their existence) may be a huge time-saver, but to someone new coming onto the project, is reminiscent of those projects which made lots of "clever" use of the C / C++ Pre-processor to add "features" to the language.
PostSharp is even more insidious though, as it modifies the CIL after compilation, so things will just behave in bizarre ways, with side effects you can't see by looking at the code, even in a debugger.
After seeing the "clever" deployment of AOP in this project, I think it may be better in the long run to go through the drudgery (or even better, get a Junior to go through the drudgery) of handling some things manually (the old fashioned way), such that they're transparent and obvious when it comes time to maintain the app 5 years down the line.
Admin
Automapper really just helps to remove boilerplate and infer as much as it can without requiring lots of error prone manual coding. I agree that incorporating too much "magic" automation into a project makes it significantly harder to debug, especially in corner cases where the tool in question wasn't really designed to be used. It's all a matter of compromise and a good architect should understand this.
We have a C# project which HEAVILY utilizes PostSharp (an aspect oriented programming tool, which modifies CIL bytecode after compilation. Yes, it removes an awful lot of boilerplate (especially if you are unfortunate enough to still be working with WPF), but it can also be used to alter the basic semantics of the language in "clever" ways, which if you understand them (or know of their existence) may be a huge time-saver, but to someone new coming onto the project, is reminiscent of those projects which made lots of "clever" use of the C / C++ Pre-processor to add "features" to the language.
PostSharp is even more insidious though, as it modifies the CIL after compilation, so things will just behave in bizarre ways, with side effects you can't see by looking at the code, even in a debugger.
After seeing the "clever" deployment of AOP in this project, I think it may be better in the long run to go through the drudgery (or even better, get a Junior to go through the drudgery) of handling some things manually (the old fashioned way), such that they're transparent and obvious when it comes time to maintain the app 5 years down the line.
Addendum 2020-09-21 08:06: Duplicate Post... Sorry. My browser seems to do this a lot on this site.