Forums
Code Snippet Of the Day (CodeSOD) features interesting and usually incorrect code snippets taken from actual production code in a commercial and/or open source software projects.
Good intentions are never enough. If they aren't coupled with the wisdom to follow through properly, they can result in a horrible mess. Today’s Anonymous submitter has learned this the hard way:
Paulo F was doing a little online banking with one of the largest banks in Brazil. He wanted to buy a pre-paid debit-card. He chose a value from the drop-down, for example R$50,00- fifty Reals. The site promised him a card loaded with R$200,00. It didn’t matter what he chose, the site offered him a completely different value.
Curious, he pulled up the element in the inspector.
Let’s talk a little bit about front-end development. Even at its best, it’s terrible- decades of kruft mixed with standards and topped off with a pile of frameworks that do their best to turn this mess into a cohesive whole.
Jameson is suffering through this, and his suffering is the special level of front-end suffering known as “Angular”. Angular bolts Model-View-Controller semantics on top of HTML/JS/CSS, and its big selling point is that it makes two-way data-binding trivially easy.
Let’s say you have a collection of objects which contain geographic points. You want to find a specific item in that collection, and then extract the lat/lon of that item. You might write code like:
Jul 16 var point = userGeoPositions.Where(x => x.userId = userId);
decimal lat = point.Latitude;
decimal lon = point.Longitude;I did a brief contract with Hershey, the candy manufacturer, once. The biggest thing I recall from the experience was that they had bowls full of candy all over the place. You could just grab them by the handful.
I bring this up, because Brenda worked for a pharmaceutical company, and I can only assume that there are bowls full of random drugs scattered around, and someone has been chowing down on them by the handful. That’s the most logical explanation for the following code:
Imagine you’re a financial institution. You’ve built an application that processes financial transactions, and there are a number of flags that need to be set as constants to determine application behavior.
You might choose to write code like this:
Modern object-oriented languages tend to support the concept of “reflection”. Reflection lets you inspect an object and find out its methods and invoke them dynamically. If you’re building extensible frameworks where you’re handling objects where their type might not be known until runtime, it can be very useful. On the other hand, if you’re using a strongly typed language and find yourself in this situation frequently… you’re probably doing something wrong.
For that reason, when Adam encounters calls to method.invoke() in Java programs, he gets suspicious. So, when he saw this: