donderdag 24 juli 2014

To BC or not to BC?

A few weeks ago there was a vote to change the behavior of PHP.

This change has the ability to break existing code, so obviously some people are in favor and some are against.

Those who vote for the change see an opportunity to make their code more consistent and therefore faster to debug and more reliable in the long term.

Those who vote against see a lot of debugging work when the change is applied, with minimal benefits for the future.

As you may have guessed, I am a proponent of any change that makes a language more consistent. I adore Python for it's attitude of "you only need one way to do something, so that's all you get" and I love languages that use strict typing, specifically because it prevents this kind of problems
Do the BC protesters have a point? Absolutely, but they are making the point from deep down a hole that they dug for themselves, while furiously shoveling "straight down". If your codebase grows to the size where you have to worry about changes in behaviour in PHP then you have a responsibility to yourself to write tests. Today's development tools are such that writing tests hardly takes any extra time and it completely voids this "Ohnoes, don't change PHP or my code will break!" argument.

So yes, please PHP, become more consistent. Incorporate HHVM while you are at it, and become a real programming language.

dinsdag 15 juli 2014

Why I like JetBrains IDE's: modifications history with unittest results.

Test-driven-developement can greatly improve your development speed and quality. Everytime you make a few changes you can simply run the tests to see if you've completed the feature you are working on, and whether you have broken anything else. When something else breaks then you have to revert, or at least review, the changes you made.

Jetbrain's tools all keep a history of changes made to each file over time, which is pretty cool by itself, but if you're like me, you will have made dozens of changes since the last test and you really can't remember exactly which changes came after the last  successful test.

Jet brains to the rescue!

If you use a JetBrains IDE to run your tests then if will keep track of the testresult in the history. Successfuil tests show up as a green line, failed tests show up as a red line. Now you can accurately review only those changes that came after the last successful test and not worry about forgetting changes or reverting too much.

zaterdag 12 juli 2014

3d printing hype

Plastics have been used in medicine for decades, and nobody acts surprised when some bodypart is replaced by a plastic replica.

So why is it big news whenever that part is created using a 3d printer? I don't know, because the regular plastic parts are created using a CNC-machine, which is the exact same machine as a printer, except it begins with a solid block of plastic and removes the bits that don't look like the final part.

The only reason why you could want to use a printer instead of CNC is that a printer can create hollow shapes directly, where CNC would have to create to halves that have to be glued together.

So please, stop mentioning that a particular part was created using a 3d printer. You don't specify any other manufacturing processes, so why 3d printing, which is nothing special anyway.

vrijdag 11 juli 2014

"You can read the code, right?"

A few weeks ago I talked to a programmer who insisted that you should not add comments inside your code to explain what you are doing. His argument was that this documentation will quickly get outdated as the code evolves, and incorrect documentation is worse than no documentation. Reading the code tells you exactly what the current code does. I asked him why he didn't just update the docs along with the code, but apparently that was just a silly question, he didn't write docs, end of story.

I've seen this kind of behaviour a few times before and always in bad programmers. Not just bad as in "he doesn't stick to convention", but bad as in "his software does not work". And why doesn't it work? Because he has no documentation to stick to. Every time he modifies a routine he has to think back to the time when he first created the routine, to try to remember what it is supposed to do. This works exactly once, and after a month he really does have to read the code.

But, the code does not tell him that there is another routine a somewhere else in the code, that requires that once IF statement so it will never return -1. So when a complaint comes in that the value -1 cannot be used, where is nothing stopping him from removing that, apparently useless, IF statement. a few days later it turns out that the other routine has been messing data up bigtime.

Yeah, let's not document routines, good idea.

dinsdag 8 juli 2014

"Loosly typed languages make you a better programmer"

Loosely typed languages are sometimes thought to make you a better programmer because you have to do a lot more checking while you are writing software.

The sad truth, of course, is that you don't. We've all stared at the screen wondering why $t refuses to increase inside a loop, only to find that there a few lines later, just off-screen, there is a line that assigns TRUE to $t. And we've all sighed and whispered "why doesn't it tell me I can't do that...."

There is nothing good about being loosely typed. People often say that it's "convenient", but... how? Is it really so much work to use two variables instead of one? Does your code become in any way more readable if you re-use variables for different kinds of data? Does finding bugs become easier?

Isn't it at least a little strange that in PHP it's perfectly acceptable to use ctype_digit((string) $var) to check if a variable contains an integer? How is that better than defining $var as an integer, after which it is simply guaranteed to be an integer?

Somebody, tell me what's good about loosely typed variables...

maandag 7 juli 2014

Use the tools Luke! PHPStorm's conditional breakpoints.

Debugging PHP can be hell because of it's hilarious variable-variables that seem to be very attractive to programmers who want to prevent repeating themselves by creating template-code and using said variable-variables instead of the regular names.

Regular debugging by printing rude words at lines of code that seem important just yields endless lists because the routine is repeated over and over and over, doing the same task dozens of times, evaporating the rainforest to save the programmer a few keystrokes.

PHPStorm to the rescue!

Every PHP developer knows about xDebug (if you don't: google it NOW, and don't come back until you know what it is and have decided to use it from now on) but regular breakpoints are not much more useful than the print statements, because your script just keeps stopping at the same breakpoint over and over.
In PHPStorm you can modify the breakpoint to observe the current context. You can tell PHPStorm/xDebug to only break at a particular breakpoint if a certain variable in the context meets a requirement. For example; you can make one of those idiotic variable-variable routines break only when the offending variable variable contains a particular value. Or you can disable the breakpoint inside a loop when the loop has iterated more than two times.

Even more interesting; you can make the breaking of a breakpoint dependant on whether another breakpoint has been visited yet. This means that you can put a breakpoint in a dispatcher and only make it break when it is called after some variable-variable-fart has executed one particular variable.

These two simple features mean that you can really make your script stop where you need it to, and you don't have to press F7 a million times, before accidently pressing F8 and skipping the one bit you actually wanted to see.