GOOD MORNING CAMPERS!
Yes it’s another Barcamp, this time in Sheffield. Last light saw the pre-camp party, where vast quantities of alcohol were imbued by many, and the rest of us stood around to watch the tomfoolery. We’re now into the registration part of the Saturday session and people are starting to gently dribble in, some nursing serious hangovers. Hopefully we’ll be able to live blog some of the details as we go for those of you unable to attend.
The below are mostly crib notes. I make no claims to the accuracy of the content below, or that the speakers even spoke at the time.
(Click here to read the rest of this entry)
It’s one of the first keywords every programmer is taught, and it’s the first real sense of control you’re given over your programming. It’s translated into almost every language (there is the odd exception, and they are odd) and makes the basis for every conditional statement there-in.
Yes, we’re talking about the “if” statement. Everybody is familiar with its structure – if condition x is satisfied do this, or else do that, where this and that can be as flexible as you like. Alternatives exist, although most programmers seem to learn to “switch” and stop there. Because all their use cases can be covered with the “if” statement, programmers can become dependant on the “if” statement to perform functions that are better suited by other operators or keywords.
Why make the effort? This boils down to maintainability and readability. By using the most appropriate method to define your “if”, you explicitly state your intended purpose. When the next programmer comes along to maintain your code, or if you revisit your code after a significant time (say a week) the meaning of the statement is inherently obvious and rather than wasting time attempting to understand the complexities of the “if” blocks, you can concentrate on more important things. This is always a good thing. There may be some performance benefits (or occasionally losses) to some of these methods, but for the moment we are focusing on maintainability and readability of your code.
(Click here to read the rest of this entry)
Kian Ryan is a 
