Shit programmers write
shitprogrammerswrite.com
shitprogrammerswrite.com
Maybe we should reevaluate some best practices. I have debated before on here that many unit tests seem useless as the units are too small, and you essentially end up testing your language or framework which you already know works. Integration testing on the other hand makes a lot more sens.
When I started with Java, it seemed appropriate to put hundreds of getter / setter methods. Is there much advantage to that over allowing the variable to be accessed directly? (Perl felt very strange at first having getter and setter methods combined as one method).
As I get more experienced as a developer, my skill set has grown but my coding becomes simpler. Don't use every language feature to show how knowledgeable you are. Use it when appropriate, and when it makes the code more readable / reusable / simpler. Sometimes a higher level abstraction is more difficult to understand , but is overall better choice. An example would be a map as opposed to a for loop. Less chance of side effects in a map, as we don't have to track the iterator variable, but a map is not as intuitive for less experienced coders.
As I mature as a developer I notice that it takes more and more time for me to finish something. When I was younger I simply wasn't aware of half the stuff that could go wrong. Now I'm older and I am aware I find myself taking more and more time to implement something and spend a lot more time on e.g. clean interfaces and error handling. Something I simply didn't do many many years ago.
Oh my yes. As soon as you need more than one processor messing with an object they are invaluable. The only thing better is immutable objects.
It's also nice to have the object interface separate from object data if you want to change the object data representation without breaking everything (I don't know in general when you would do this, I just know I have done it before and getter/setters let me work faster to refactor).
return bolReturn;
}The above actually seems reasonable if you assume the programmer that wrote it was intelligent. I'm imagining that the above code is called multiple times by the application, for a new optional feature in development. Currently, they haven't developed the feature, and so we are always returning false. But in the future, we likely will want to show the feature given some condition. So this programmer has (hopefully) decided that (s)he will write the current code to take this future development into account, and rather than pass some boolean or config value throughout the code, has isolated it to one specific method.
Now, when they go to implement Optional, whatever that is, that developer can just update this one method with the expression, and go about coding their feature without any knowledge of the previous code base, which is exactly what's supposed to happen.
return false;
Done. public bool ShowOptional()
{
return false;
}
? return foo == null ? null : foo;Rather, it "evolves".
It starts as:
return foo == null ? error_handler(bar) : foo;
And someone realizes error_handler actually does nothing, so replaces all calls with null, mechanically.Or maybe it's just stupid.
Sometimes you just can't tell the difference.
The same is probably true for this one here:
public bool ShowOptional() { bool bolReturn = false;
return bolReturn;
}There should be descriptions why the code snippets are supposed to be interesting, your and my example just look like legacy code to me.
return !foo ? null : foo; return foo || null;
if you're into that sort of thing return foo == null ? true : false;"Hmmm, if 'foo == null' is true, than it's true... I see..."
Seriously..
function isAvailable(){ objInDb = findByName('Joan Carlos'); // the object or false
return objInDb ? true : false;
}But all this could be because I'm a noob in a language I don't really know... Php that magical land where nothing is what it looks like and is always ready to stab you in the back, can't say I'm a fan of it... Or dynamic languages, or anything magical... Ok, I'm going to places I don't want to remember, sorry...
return foo ? true : false;
or even return foo == true ? true : false;You are missing the point, which is it's really silly to transpose a boolean into a boolean using a ternary operator.
If you want to argue that "foo == null" is the problem due implicit nil value falseness, than the solution is simply to use strict comparison operator "===", transposing "foo == null" into a boolean doesn't solve the falseness issue if you think this is what the original author was trying to address.
function nop()
{
if (Math.random() == 0.1234567890)
{
for (var i = 0; i < arguments.length; i++)
{
console.log(arguments[i]);
}
}
}
wouldn't have been written in JavaScript, my guess would be that this is an attempt to create an empty function (no-op) and prevent it from being optimized away by the compiler. Still unclear who may need to call it.This feels horribly familiar. I'm not sure to recognize the specific language used, but there must be cases where one would like to target empty of filled with non processable characters strings only, and let null and falsy values pass through. This kind of use would typically need a line of comment, but hey...
That if is equivalent to if (startDate + true)
EDIT: I was wrong. I haven't slept.
2) even if == had a higher precedence, then 1 == 2 would still be false :D
Though not sure why it was required for this particular comparison.
I've written similar Java code for that reason.
if "x$VARIABLE" == "x"
because it handles the cases where $VARIABLE is undefined or multiple words without vomiting all over the place. if [[ "$VARIABLE" == "" ]]
or even better if [ -z "$VARIABLE" ]
will handle undefined, empty and multiple words just fine. if [[ -z "${VARIABLE:-}" ]] if (Math.random() == 0.1234567890)
{
for (var i = 0; i < arguments.length; i++)
{
console.log(arguments[i]);
}
}
Reminds me of the code I have to insert to prevent overzealous compilers from completely optimizing away my benchmark loops."I Don’t Know".ToJson();
public string ToJson()
{
var s = new StringBuilder("{");
for (var i = 0; i < CustomField.CustomFieldOption.Count; i++)
{
var item = CustomField.CustomFieldOption[i];
s.Append("\"" + item.CustomFieldOptionId + "\"");
s.Append(":\"" + item.OptionName + "\"");
if (i < CustomField.CustomFieldOption.Count - 1)
{
s.Append(",");
}
}
s.Append("}");
return s.ToString();
}I notice that the two pieces of data actually going into the JSON are "CustomFieldOptionId" and "OptionName" -- which seem somewhat useless/obscure, but there could be a legitimate reason for that.
So yeah, I don't quite get it either. Most of the others are more obviously silly.
About 6 years ago I wrote something similar, but that was before newtonsoft.json was super popular.
var item = CustomField.CustomFieldOption[i];
Shouldn't that be the item to convert? This looks like something stuck onto a class to serialize to JSON.I might be missing the joke also :(
Deleted comment
Just note that s is a StringBuilder and not a string.
I'm pretty sure there hasn't been reason for anyone to do that for a decade or so, though.
Maybe I'm missing a button somewhere, but I needed to open up the DOM inspector or RSS feed to read every single one.
Unacceptable
I once had to print a method that took 50 pages of paper, so I could understand what it does, and after 15 minutes I realized it's the same 60 lines repeated over and over with different conditions. The guy who wrote it had no idea he could have extracted a method.
On the plus side, the code still had comments for the punchcard numbers, so it was pretty easy to keep the pages in order :)
Sometimes, if you're really lucky, the blocks of working code don't modify their own conditionals, and you can 'fold' them and just look at the if's and loops...
Also, faster and more flexible annotation (drawings, etc), but that's secondary.
I just found the picture I took that day. The boxing gloves just happened to be in the same conf room.
A 4x6 table has far more surface area than even the biggest multi monitor set up
It's not meant to be specific to any language. It's just funny shit people have written.
I submitted a few from old code I wrote like 5 years ago. Its all good fun :)